git-integrate

Git 集成

负责一次变基、合并、摘取或还原操作，直至确认完成。用户请求集成或恢复，且已有操作正在进行时，应继续或修复该操作。无关任务、审查或问题并不授权恢复历史操作。否则，明确启动用户要求的操作。这不是通用 Git 命令运行器：不要自行选择集成策略，也不要执行无关的提交、分支、贮藏、重置、远程仓库或工作区维护操作。

严格停止： 对于新操作，只有在请求、仓库策略或现有配置已明确所请求的操作及预期历史时，才继续。对于正在进行的操作，如果 Git 状态已明确操作及下一步动作，则直接继续，无须用户重述方法或目标。只有在仓库证据也明确预期结果时，才能解决冲突。否则，在修改 Git 或文件之前停止，并向用户提供具体选项。绝不自行选择默认选项；错误的历史操作或冲突解决比中断操作更糟。

工作流

1. 检查状态。 运行完整的 git status、git status --short --branch，并在可用时运行 scripts/inspect-operation.sh。记录当前分支和 HEAD。使用 git rev-parse --git-path 查找 rebase-merge、rebase-apply、MERGE_HEAD、CHERRY_PICK_HEAD、REVERT_HEAD 和 sequencer 目录。

   当前 Git 状态决定要继续的操作；不要启动其他操作，也不要询问用户是否改选新方法或目标。但仅凭当前状态无法确定预期的合并行为，也不能证明立即执行 --continue 就是正确操作。

2. 继续正在进行的操作。 阅读 git status、操作元数据和待办状态、当前操作提交、未合并的索引阶段、已暂存的更改以及工作区更改。判断操作是否已准备好继续，还是因冲突、编辑指令、exec 执行失败、空提交、待处理提交或其他原因而暂停。

   对冲突，按下方的冲突解决工作流处理。对于编辑或 exec 执行失败，继续之前先验证所要求的编辑或命令结果。对于空提交，必须先获得明确批准，才能保留、丢弃或跳过。如果暂停原因或下一步操作不明确，保留原样并询问；绝不要仅因操作处于活动状态就盲目继续。

3. 新操作的预检。 没有正在进行的操作时，必须明确指定方法，并提供足够信息以确定其对历史的确切影响：

   • 变基：当前分支或指定源分支、上游、要重放的提交，以及请求是否要求使用 --onto、--rebase-merges、--update-refs、自动压缩提交或其他非默认形式。
   • 合并：源和目标，以及预期的快进策略：--ff-only、允许快进，或使用 --no-ff 要求创建合并提交。
   • 摘取：确切的提交及其顺序，以及空结果应暂停、丢弃还是保留。
   • 还原：确切的提交及其顺序，并确认每个合并提交使用的 -m <parent>。

   将命名引用解析为提交 ID，并在修改历史之前检查合并基点、分叉情况、提交及相关差异。识别已有的已暂存、未暂存和未跟踪更改；只有在其归属明确且不会相互影响时，才能在保留这些更改的情况下继续。仅在新鲜度确有影响时，才获取所需的远程仓库或引用。检查会影响行为的配置，例如 merge.ff、rebase.autoStash、rebase.rebaseMerges、rebase.updateRefs 和 rerere.enabled；如果配置会实质性改变结果，请使用明确的标志或询问用户。

   不要选择用户未要求的集成方法，不要改变预期的提交拓扑，也不要贮藏无关工作。常规选项使用仓库已有配置；如果不同选项会实质性改变请求的结果，则应询问用户。记录原始分支、HEAD 和相关引用，以便最终比较历史。

4. 启动已确认的操作。 根据已确认的历史形态构造命令，而不是强行让每个请求都使用简单形式。基本形式包括 git rebase <upstream>、git merge --no-edit --ff-only <source>、git merge --no-edit --ff <source>、git merge --no-edit --no-ff <source>、git cherry-pick <commits> 和 GIT_EDITOR=true git revert <commits>。只有在已确认时才添加变体标志或 -m <parent>。如果非交互式运行能够保留所请求的提交消息和行为，就采用非交互式运行。

5. 编辑前检查每个冲突。 检查 git diff --name-only --diff-filter=U、git ls-files -u、git diff --cc、冲突标记，以及 REBASE_HEAD、CHERRY_PICK_HEAD、REVERT_HEAD 或 MERGE_HEAD 所代表的确切更改。根据周边历史、调用方、测试和文档，说明每个路径的预期结果及其依据。

   对预期结果已明确的独立路径进行解决。保留预期行为仍有冲突的路径并询问用户；不要因此阻止对明确路径的检查或准备。报告确切的 Git 状态和路径，解释相互冲突的意图及其依据，并提供具体选项。你可以指出最可能的选项，但不得自行选择。对于行为分歧、含义不明的删除/修改冲突、不确定的二进制文件/锁定文件/生成文件、相互竞争的重构或依据，以及缺少主线父提交的情况，始终要询问。只有当仓库依据能够验证结果时，格式调整、导入、非重叠编辑、移动和生成文件才可直接处理。

6. 解决并验证。 将已暂存的解决结果、rerere、合并驱动程序和自动解决结果都视为未经信任的提议。所有路径都明确后，编辑文件，从源文件重新生成生成的输出，移除所有冲突标记，并且只暂存已解决的路径。确认没有未合并条目，检查已暂存的解决结果，并在中间状态可测试时运行最快且有意义的定向检查。未经独立验证，绝不全盘接受 ours、theirs、联合合并或生成的输出。

7. 继续正在进行的操作。 当 Git 状态表明当前步骤已就绪时（包括解决冲突后或确认待处理操作提交后），使用相应命令：

   • GIT_EDITOR=true git rebase --continue
   • GIT_EDITOR=true git merge --continue
   • GIT_EDITOR=true git cherry-pick --continue
   • GIT_EDITOR=true git revert --continue

   每次继续后都要重新检查状态。对之后每次暂停应用相同的分类和硬性停止规则；未经验证所需操作，不要因其他停止原因而使用 --continue。

8. 验证完成情况。 确认操作状态文件已消失，最终分支和 HEAD 符合预期，并且所请求的提交和拓扑均存在，没有意外丢弃或重复。对于非简单变基，在可行时使用 git range-diff 或同等依据比较新旧提交序列。运行定向验证，检查最终状态和剩余更改，然后报告所执行的操作、已解决的路径、历史验证、验证结果和树的剩余状态。

Ours 和 Theirs

• 变基：ours 是新基底上累积的变基结果，包括已重放的提交；theirs 是当前正在重放的提交。
• 合并：ours 是当前分支；theirs 是正在合并的分支。
• 挑拣提交：ours 是当前 HEAD，包括序列中先前挑拣的提交；theirs 是正在应用的提交。
• 撤销提交：不要根据这些标签推断任何内容；应比较当前 HEAD、被撤销的提交、所选父提交和索引阶段。

安全

未经明确批准，绝不要执行破坏性重置、中止或退出操作、跳过或丢弃提交、覆盖无关更改，或更改所请求的历史拓扑。如果无法确定是否已完成或操作是否安全，请保留当前状态，并询问是否提供解决指南、使用相应的恢复命令，或选择其他集成策略。

scripts/inspect-operation.sh 会输出当前活动的操作、当前分支和提交、操作元数据、已暂存和冲突的路径、索引阶段以及标记位置。