# Git Commit Push

> 当用户明确要求“解决当前 merge / rebase / cherry-pick 冲突、提交代码、创建 commit、把改动分批提交并 push、推送当前分支”时使用。进行中的冲突要先识别 Git 操作和双方原始意图，逐 hunk 做语义合并并运行项目检查，再经用户确认继续操作；普通改动要检查敏感信息与异常差异，拆成可运行、可审查、可回滚的原子提交后确认提交和推送。不得自动发起或中止 merge / rebase / cherry-pick，不得强推或随意改写已发布历史。不要用于普通改动尚未完成或验证失败、只想查看 Git 状态，或要创建 PR 的场景。

- Skill: `rollrollroll/git-commit-push` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add rollrollroll/git-commit-push`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rollrollroll/git-commit-push/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: RollRollRoll (https://skillmd.com/u/rollrollroll)
- Updated: 2026-08-19
- Page: https://skillmd.com/skills/rollrollroll/git-commit-push

---


# Git Conflict Resolution, Commit & Push

## 目标

安全完成两类相邻工作：

- 对进行中的 merge / rebase / cherry-pick，追溯冲突双方的原始意图，逐处完成语义合并、验证并在确认后继续操作。
- 对普通工作区改动，整理成一个或多个**单一逻辑变更**，确保每个提交可运行、可审查、可回滚，再把确认过的提交推送到用户指定的远端。

只处理**已经开始的冲突操作**、提交与推送。不要自行发起或中止 merge / rebase / cherry-pick，不要顺手创建 PR、清理工作树、扩大实现范围或重写已发布历史。

## 调用契约

这是 agent-toolkit 的 **composable 层**能力单元，可由用户直接触发，也可被其他 skill 调用。

**传入**

- **目标动作**：解决进行中的冲突 / 提交 / 推送（可组合）。
- **目标 remote 与分支**：有多个 remote 时必须指明，不默认全部推送。
- **验证命令**（可选）：每个提交批次要跑的测试、构建或静态检查。

**取回**

- 当前分支与最终工作区状态；冲突操作类型、已解决文件与关键意图取舍。
- 每个新提交的短 ID 与标题、每个 remote 的推送结果。
- 未提交 / 未推送 / 未验证 / 被排除的内容，以及已建议但尚未处理的 `.gitignore` 项。

**本 skill 不做**

- 不发起或中止 merge / rebase / cherry-pick；不强推、不改写已发布历史；不创建 PR、不清理工作树。
- 不自动 stash、丢弃或覆盖用户改动；不在未确认前执行 commit / push / continue。

**与 execute-task 的边界**：execute-task 每任务的"代码 + 测试 + checkbox 原子提交"是它的闸门动作，
由它自己完成，不走本 skill。本 skill 用于独立的分批提交、推送，以及进行中的冲突解决。

## 工作流

### 1. 只读预检

先读取仓库内适用的 `AGENTS.md`、`CLAUDE.md`、贡献指南和提交规范，然后检查：

- 确认位于 Git 仓库，并获取仓库根目录。
- 使用 `git status --short --branch` 检查暂存、未暂存、未跟踪和分支状态。
- 使用 `git branch --show-current` 确认当前分支；若为 detached HEAD，判断是否由已识别的 rebase 引起，其他 detached HEAD 状态停止并让用户决定目标分支。
- 使用 `git diff --name-only --diff-filter=U`、`git ls-files -u` 和 `git status` 检查未解决冲突，并识别进行中的 merge、rebase 或 cherry-pick。
- 使用 `git remote -v`、分支 upstream 和 push 配置识别可用远端；不要只凭远端名猜测目标。
- 检查当前分支与本地已知 upstream 的领先 / 落后关系，同时说明远端跟踪信息可能尚未刷新。

按预检结果路由：

- 存在未合并条目或已识别的进行中操作：若用户明确要求解决冲突，完整读取并执行 [冲突解决流程](references/conflict-resolution.md)；若用户只要求提交或推送，先报告操作类型和冲突文件，取得扩展到冲突解决的授权后再编辑。
- 存在未合并条目却无法识别对应操作：停止并询问这些条目的来源，不猜测应该继续哪种 Git 操作。
- 没有进行中操作但本地已知 upstream 位于当前分支之前：停止并让用户选择后续集成方式；不自动 pull、merge 或 rebase。
- 没有冲突：继续审查候选内容。

冲突流程完成后若 Git 已经生成 merge / rebase / cherry-pick 提交，不要再把它们重新包装成重复提交；用户还要求推送时直接进入安全推送，否则报告结果并结束。若操作完成后仍有独立的普通工作区改动，只把这些剩余改动送入下述提交流程。

### 2. 审查全部候选内容

同时审查已暂存、未暂存和未跟踪内容，不能只看 `git diff`。保留入场时的暂存状态，不要自动 unstage、
stash、丢弃或覆盖用户改动。

重点检查：

- **敏感信息**：密钥、token、密码、私钥、证书、连接串、`.env`、凭据文件和包含秘密的配置。
- **无用内容**：日志、缓存、临时文件、编辑器文件、构建产物、覆盖率结果和意外生成的大文件。
- **无关改动**：不属于本次目标、来源不明或用户已有的修改。
- **异常差异**：大面积格式化、整文件换行符变化、意外二进制文件、重命名或删除。
- **换行与权限**：结合 `.gitattributes`、`git ls-files --eol`、`git diff --summary` 和
  `git diff --check` 检查 EOL、可执行位和文件模式变化。

不要在输出中展示秘密值；只报告文件路径、疑似类型和处理建议。发现敏感信息时立即停止，不得暂存或提交：

1. 提醒用户移除或替换秘密，并按需轮换已暴露凭据。
2. 建议把本地秘密文件和无用生成物加入 `.gitignore`。
3. 若文件已经被 Git 跟踪，明确说明仅加入 `.gitignore` 不会停止跟踪，询问用户如何处理。
4. 若秘密可能已经进入历史，说明历史清理属于单独的高风险任务；不要在本 skill 中自动执行。

对可能本就需要纳入版本控制的生成文件或权限变化，不要武断排除；先向用户确认意图。

### 3. 设计原子提交

按“修改目的”而不是文件类型分组。代码、对应测试和必要文档通常属于同一个逻辑提交。

每个计划提交都必须满足：

- 只表达一个完整、独立、容易理解的逻辑变更。
- 不依赖尚未提交的后续改动才能构建或运行。
- 能单独审查，也能在需要时单独回滚。
- 包含证明该变更的测试或验证；无法验证时明确说明原因。

若候选改动包含不同实现逻辑，拆成多次提交。若同一文件混有多个逻辑，按 hunk 精确暂存；无法安全拆分时
停止并说明阻碍，不要为了凑原子提交而改写用户代码。不要盲目使用 `git add .` 或 `git add -A`。

为每个批次给出：

1. 修改目的。
2. 包含的文件或 hunk。
3. 拟用提交标题；复杂提交同时给出正文。
4. 对应验证命令。

### 4. 编写提交信息

优先遵循仓库既有提交规范。若仓库没有约定，使用简短、明确、可搜索的标题，直接说明“做了什么”及其目的；
只有仓库本来使用 Conventional Commits 时才沿用其格式。

避免 `update`、`fix bug`、`misc changes`、`调整代码` 等模糊描述。复杂提交必须添加正文，至少说明下列
必要信息中的两项：背景 / 原因、关键实现决策、行为影响或兼容性、风险与验证方式。正文解释“为什么”，
不要把 diff 文件列表重复一遍。

示例：

```text
fix(config): 避免缺失字段时覆盖现有设置

导入部分配置时只更新显式声明的字段，保留本机未声明设置。
这样可以避免跨设备同步时意外清空平台专属配置。
```

### 5. 取得一次明确授权

在任何 `git merge --continue`、`git rebase --continue`、`git cherry-pick --continue`、`git commit` 或 `git push` 前，向用户展示并确认：

- 当前分支。
- 若处于冲突流程：操作类型、每个冲突的意图判断与解决结果、取舍、验证结果和准备执行的 continue 命令。
- 每个提交批次及完整提交信息。
- 将运行的验证及尚未验证内容。
- 目标 remote、源分支和目标分支。
- 是否需要设置 upstream。

一个确认可以覆盖已完整列出的操作序列；若 rebase / cherry-pick 继续后出现新冲突，或范围、解决决定、提交信息、分支、remote 发生变化，重新确认。当前确认不能预先覆盖尚未出现的冲突。

有多个 remote 时，必须询问推送到哪一个或哪些 remote，不能默认全部推送。pull 同理：只有用户明确要求 pull
时才执行，并先让用户选择准确的 remote 和分支；不要使用隐含来源的 pull，也不要把多个 remote 自动合并。

### 6. 分批暂存、验证并提交

对每个获批批次依次执行：

1. 只暂存该批次的明确路径或 hunk。
2. 使用 `git diff --cached --stat`、`git diff --cached --summary`、
   `git diff --cached --check` 和完整 staged diff 复核范围。
3. 再次确认暂存区没有秘密、无用文件、异常 EOL / 权限或其他逻辑。
4. 运行该批次的相关测试、构建或静态检查；测试环境含有后续未提交改动时，说明验证并非隔离结果，
   不要声称该提交已被独立验证。
5. 仅在检查通过后创建提交，然后核对提交 ID、标题和剩余工作区状态。

若暂存内容与获批计划不一致，停止并重新展示差异。验证失败时不要提交“红灯”状态，也不要擅自修改实现；
报告失败并让用户决定返回开发还是调整范围。

### 7. 安全推送

推送前重新检查当前分支、upstream、待推送提交和工作区状态。使用明确 remote 与 refspec 的命令，避免裸
`git push` 意外触发非预期配置；没有 upstream 时，只有在用户确认后才设置。

- 不默认推送 tags、其他分支或所有 remote。
- 多个获批 remote 按顺序推送，并分别记录成功或失败；部分成功时如实报告，不重写已成功远端。
- 推送因 non-fast-forward、远端更新或策略拒绝时立即停止。请用户先选择并完成合并 / rebase 等集成动作，
  不要自动 pull、merge、rebase 或强推。
- 不使用 `--force` 或 `--force-with-lease`。任何历史改写必须脱离本流程，作为单独高风险任务明确评估和授权。
- rebase 解决完成后若远端分支只能通过强推更新，报告本地已完成状态和推送阻碍后停止；不要因为 rebase 已获授权就推导出强推授权。
- 已推送提交需要修正时，默认创建新的修正提交，不使用 amend、reset 或 rebase 改写已发布历史。

### 8. 报告结果

完成后报告：

- 当前分支和最终工作区状态。
- 冲突操作类型、已解决文件、关键意图取舍，以及 merge / rebase / cherry-pick 是否完成。
- 每个新提交的短 ID 与标题。
- 每个 remote 的推送结果及目标 ref。
- 未提交、未推送、未验证或被排除的内容。
- 已建议加入 `.gitignore` 但尚未处理的文件或模式。

不得把提交成功等同于推送成功，也不得在部分失败时笼统报告“已完成”。

## 禁止事项

- 不提交或输出敏感信息。
- 不把不同实现逻辑塞进一个提交。
- 不靠删除冲突标记、整文件选 `ours` / `theirs` 或让测试通过来替代语义判断。
- 不自动发起、跳过或中止 merge / rebase / cherry-pick；用户要求这类动作时单独说明影响并取得授权。
- 不在用户确认解决摘要和验证结果前执行任何 continue 命令。
- 不自动 stash、丢弃、清理或覆盖用户改动。
- 不修改已经推送的历史，不强推。
- 不在用户未确认当前分支、提交批次和远端目标时执行 commit 或 push。