RollRollRoll 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 的领先 / 落后关系，同时说明远端跟踪信息可能尚未刷新。
按预检结果路由：
- 存在未合并条目或已识别的进行中操作：若用户明确要求解决冲突，完整读取并执行 冲突解决流程；若用户只要求提交或推送，先报告操作类型和冲突文件，取得扩展到冲突解决的授权后再编辑。
- 存在未合并条目却无法识别对应操作：停止并询问这些条目的来源，不猜测应该继续哪种 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、可执行位和文件模式变化。
不要在输出中展示秘密值；只报告文件路径、疑似类型和处理建议。发现敏感信息时立即停止，不得暂存或提交：
- 提醒用户移除或替换秘密，并按需轮换已暴露凭据。
- 建议把本地秘密文件和无用生成物加入
.gitignore。 - 若文件已经被 Git 跟踪，明确说明仅加入
.gitignore不会停止跟踪，询问用户如何处理。 - 若秘密可能已经进入历史，说明历史清理属于单独的高风险任务；不要在本 skill 中自动执行。
对可能本就需要纳入版本控制的生成文件或权限变化，不要武断排除；先向用户确认意图。
3. 设计原子提交
按“修改目的”而不是文件类型分组。代码、对应测试和必要文档通常属于同一个逻辑提交。
每个计划提交都必须满足：
- 只表达一个完整、独立、容易理解的逻辑变更。
- 不依赖尚未提交的后续改动才能构建或运行。
- 能单独审查，也能在需要时单独回滚。
- 包含证明该变更的测试或验证；无法验证时明确说明原因。
若候选改动包含不同实现逻辑，拆成多次提交。若同一文件混有多个逻辑，按 hunk 精确暂存；无法安全拆分时
停止并说明阻碍，不要为了凑原子提交而改写用户代码。不要盲目使用 git add . 或 git add -A。
为每个批次给出：
- 修改目的。
- 包含的文件或 hunk。
- 拟用提交标题；复杂提交同时给出正文。
- 对应验证命令。
4. 编写提交信息
优先遵循仓库既有提交规范。若仓库没有约定，使用简短、明确、可搜索的标题，直接说明“做了什么”及其目的； 只有仓库本来使用 Conventional Commits 时才沿用其格式。
避免 update、fix bug、misc changes、调整代码 等模糊描述。复杂提交必须添加正文，至少说明下列
必要信息中的两项：背景 / 原因、关键实现决策、行为影响或兼容性、风险与验证方式。正文解释“为什么”，
不要把 diff 文件列表重复一遍。
示例：
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. 分批暂存、验证并提交
对每个获批批次依次执行：
- 只暂存该批次的明确路径或 hunk。
- 使用
git diff --cached --stat、git diff --cached --summary、git diff --cached --check和完整 staged diff 复核范围。 - 再次确认暂存区没有秘密、无用文件、异常 EOL / 权限或其他逻辑。
- 运行该批次的相关测试、构建或静态检查；测试环境含有后续未提交改动时，说明验证并非隔离结果， 不要声称该提交已被独立验证。
- 仅在检查通过后创建提交，然后核对提交 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。