git-integrate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git Integrate

Git集成操作

Own a rebase, merge, cherry-pick, or revert through verified completion. If one is already in progress, take it over and continue or repair it before considering new work. Otherwise, safely start the operation explicitly requested by the user. This is not a general Git command runner: do not choose an integration strategy or perform unrelated commit, branch, stash, reset, remote, or worktree maintenance.

Hard stop: For new work, proceed only when the requested operation and history shape are 100% clear. For an in-progress operation, continue it without requiring the user to restate its method or target when Git state makes the operation and next action clear. Resolve a conflict only when its intended result is also clear from repository evidence. Otherwise stop before mutating Git or files and ask the user with concrete options. Never choose a default; an incorrect history operation or resolution is worse than an interruption.

通过已验证的完成流程负责处理rebase、merge、cherry-pick或revert操作。如果已有操作在进行中，优先接管并继续或修复该操作，之后再考虑新的工作任务。否则，安全启动用户明确要求的操作。这并非通用Git命令执行器：请勿自行选择集成策略，也不要执行无关的commit、branch、stash、reset、remote或worktree维护操作。

硬性停止规则： 对于新操作，仅当请求的操作及历史形态100%明确时才可继续。对于进行中的操作，若Git状态已明确操作内容及下一步动作，则无需用户重新说明操作方式或目标，直接继续执行。仅当仓库证据能明确冲突的预期结果时，才可解决冲突。否则，在修改Git或文件前停止操作，并向用户提供具体选项进行询问。绝不要选择默认方案：错误的历史操作或解决方案比中断操作更糟糕。

Workflow

工作流程

Inspect state. Run full
```
git status
```
,
```
git status --short --branch
```
, and
```
scripts/inspect-operation.sh
```
when available. Record the current branch and
```
HEAD
```
. Resolve
```
rebase-merge
```
,
```
rebase-apply
```
,
```
MERGE_HEAD
```
,
```
CHERRY_PICK_HEAD
```
,
```
REVERT_HEAD
```
, and the sequencer directory with
```
git rev-parse --git-path
```
.
Active Git state determines the operation to continue; do not start another or ask the user to choose a new method or target. It does not by itself establish the intended combined behavior or prove that
```
--continue
```
is the correct immediate action.
Continue an active operation. Read
```
git status
```
, the operation metadata and todo state, the current operation commit, unmerged index stages, staged changes, and working-tree changes. Determine whether the operation is ready to continue or stopped for a conflict, an edit instruction, a failed exec, an empty commit, a pending commit, or another reason.
Route conflicts through the resolution workflow below. For an edit or failed exec, verify the requested edit or command result before continuing. For an empty commit, require explicit approval before keeping, dropping, or skipping it. If the stop reason or next action is unclear, preserve the exact state and ask; never blindly continue an operation merely because it is active.
Preflight a new operation. With no active operation, require an explicit method and enough information to determine its exact history effect:
- Rebase: current or named source branch, upstream, commits to replay, and whether the request requires
```
--onto
```
  ,
```
--rebase-merges
```
  ,
```
--update-refs
```
  , autosquash, or another non-default form.
- Merge: source and target plus the intended fast-forward policy:
```
--ff-only
```
  , allow a fast-forward, or require a merge commit with
```
--no-ff
```
  .
- Cherry-pick: exact commits, order, and whether an empty result should stop, drop, or be kept.
- Revert: exact commits, order, and the confirmed
```
-m <parent>
```
  for every merge commit.
Resolve named refs to commit IDs and inspect the merge base, divergence, commits, and relevant diff before mutating history. Identify pre-existing staged, unstaged, and untracked changes; proceed with them present only when their ownership and non-interaction are clear. Fetch only the required remote or ref when freshness matters. Inspect behavior-affecting configuration such as
```
merge.ff
```
,
```
rebase.autoStash
```
,
```
rebase.rebaseMerges
```
,
```
rebase.updateRefs
```
, and
```
rerere.enabled
```
; use explicit flags or ask when configuration would materially change the result.
Do not default to rebase, choose a topology, switch branches, stash changes, or simplify a requested complex operation without approval. Record the original branch,
```
HEAD
```
, and relevant refs so the final history can be compared.
Start the confirmed operation. Construct the command from the confirmed history shape rather than forcing every request through a simple form. Basic forms include
```
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>
```
, and
```
GIT_EDITOR=true git revert <commits>
```
. Add variant flags or
```
-m <parent>
```
only when confirmed. Run non-interactively when doing so preserves the requested commit messages and behavior.
Inspect every conflict before editing. Check
```
git diff --name-only --diff-filter=U
```
,
```
git ls-files -u
```
,
```
git diff --cc
```
, markers, and the exact change represented by
```
REBASE_HEAD
```
,
```
CHERRY_PICK_HEAD
```
,
```
REVERT_HEAD
```
, or
```
MERGE_HEAD
```
. Use surrounding history, callers, tests, and docs to state the intended result and evidence for every path.
If any result is not 100% clear, resolve nothing. Report the exact Git state and paths, explain the competing intents and evidence, and offer concrete options. You may identify the likeliest option but must not select it. Always ask for divergent behavior, unclear delete/modify conflicts, uncertain binary/lock/generated files, competing refactors or evidence, and missing mainline parents. Formatting, imports, non-overlapping edits, moves, and generated files are direct only when repository evidence verifies the result.
Resolve and verify. Treat staged resolutions,
```
rerere
```
, merge drivers, and automatic resolutions as untrusted proposals. Once every path is clear, edit the files, regenerate generated output from its source, remove all markers, and stage only resolved paths. Verify no unmerged entries remain, review the staged resolution, and run the fastest meaningful focused check when the intermediate state is testable. Never accept
```
ours
```
,
```
theirs
```
, union merge, or generated output wholesale without independent verification.
Continue the in-progress operation. When Git state shows that the current step is ready, including after resolving a conflict or confirming a pending operation commit, use the matching command:
- ```
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
```
Reinspect state after every continuation. Apply the same classification and hard stop to each subsequent pause; do not use
```
--continue
```
for a different stop reason without verifying its required action.
Verify completion. Confirm the operation state files are gone, the final branch and
```
HEAD
```
are expected, and the requested commits and topology are present without accidental drops or duplicates. For a non-trivial rebase, compare the old and new series with
```
git range-diff
```
or equivalent evidence when practical. Run focused validation, inspect final status and remaining changes, then report the operation, resolved paths, history verification, validation, and remaining tree state.

检查状态。运行完整的
```
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状态决定了需要继续执行的操作；请勿启动其他操作，也不要让用户选择新的操作方式或目标。但仅凭Git状态本身，无法确定预期的组合行为，也不能证明
```
--continue
```
是正确的即时操作。
继续活跃操作。读取
```
git status
```
信息、操作元数据与待办状态、当前操作的commit、未合并的索引阶段、已暂存的变更以及工作区变更。判断操作是否准备好继续，或是因冲突、编辑指令、exec执行失败、空commit、待提交commit或其他原因而停止。
冲突需通过下方的解决流程处理。对于编辑或exec执行失败的情况，在继续前需验证请求的编辑内容或命令结果。对于空commit，在保留、丢弃或跳过前需获得明确批准。若停止原因或下一步动作不明确，请保留当前精确状态并询问用户；绝不要仅仅因为操作处于活跃状态就盲目继续执行。
新操作预检。当无活跃操作时，要求用户提供明确的操作方式，以及足够的信息来确定其对历史记录的确切影响：
- Rebase：当前或指定的源分支、上游分支、需重放的commit，以及请求是否需要
```
--onto
```
  、
```
--rebase-merges
```
  、
```
--update-refs
```
  、autosquash或其他非默认形式。
- Merge：源分支与目标分支，以及预期的快进策略：
```
--ff-only
```
  、允许快进，或通过
```
--no-ff
```
  要求生成merge commit。
- Cherry-pick：确切的commit、顺序，以及空结果应停止、丢弃还是保留。
- Revert：确切的commit、顺序，以及每个merge commit对应的已确认
```
-m <parent>
```
  参数。
将命名引用解析为commit ID，并在修改历史前检查合并基准、分歧、commit及相关diff。识别已存在的暂存、未暂存和未追踪变更；仅当变更的归属及无交互性明确时，才可在存在这些变更的情况下继续执行。当新鲜度很重要时，仅拉取所需的远程仓库或引用。检查影响行为的配置，如
```
merge.ff
```
、
```
rebase.autoStash
```
、
```
rebase.rebaseMerges
```
、
```
rebase.updateRefs
```
和
```
rerere.enabled
```
；当配置会实质性改变结果时，使用明确的标志或询问用户。
未经批准，请勿默认选择rebase、选择拓扑结构、切换分支、暂存变更或简化用户请求的复杂操作。记录原始分支、
```
HEAD
```
及相关引用，以便比较最终历史记录。
启动已确认的操作。根据已确认的历史形态构建命令，而非将所有请求都强制转换为简单形式。基础形式包括
```
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>
```
参数。当非交互式执行可保留请求的commit信息和行为时，采用非交互式执行方式。
编辑前检查所有冲突。检查
```
git diff --name-only --diff-filter=U
```
、
```
git ls-files -u
```
、
```
git diff --cc
```
、标记，以及
```
REBASE_HEAD
```
、
```
CHERRY_PICK_HEAD
```
、
```
REVERT_HEAD
```
或
```
MERGE_HEAD
```
所代表的确切变更。利用周边历史记录、调用方、测试和文档，说明每个路径的预期结果及证据。
若任何结果并非100%明确，则不进行任何解决操作。报告确切的Git状态和路径，解释相互竞争的意图和证据，并提供具体选项。你可以指出最可能的选项，但不得自行选择。对于行为分歧、不明确的删除/修改冲突、不确定的二进制/锁定/生成文件、相互竞争的重构或证据，以及缺失的主线父commit，务必询问用户。仅当仓库证据验证结果正确时，格式调整、导入、非重叠编辑、移动和生成文件才可直接处理。
解决并验证。将已暂存的解决方案、
```
rerere
```
、合并驱动和自动解决方案视为不可信的提议。当所有路径都明确后，编辑文件、从源重新生成输出、移除所有标记，并仅暂存已解决的路径。验证是否仍存在未合并条目，检查已暂存的解决方案，若中间状态可测试，则运行最快的有意义聚焦检查。绝不能未经独立验证就全盘接受
```
ours
```
、
```
theirs
```
、联合合并或生成的输出。
继续进行中的操作。当Git状态显示当前步骤已准备就绪（包括解决冲突或确认待提交的操作commit后），使用匹配的命令：
- ```
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
```
。
验证完成状态。确认操作状态文件已删除，最终分支和
```
HEAD
```
符合预期，请求的commit和拓扑结构已存在且无意外丢弃或重复。对于非平凡的rebase，若可行，使用
```
git range-diff
```
或等效证据比较新旧提交序列。运行聚焦验证，检查最终状态和剩余变更，然后报告操作情况、已解决的路径、历史验证结果、验证过程以及剩余的工作区状态。

Ours And Theirs

Ours与Theirs语义

Rebase:
```
ours
```
is the accumulated rebased result on the new base, including commits already replayed;
```
theirs
```
is the commit currently being replayed.
Merge:
```
ours
```
is the current branch;
```
theirs
```
is the branch being merged.
Cherry-pick:
```
ours
```
is the current
```
HEAD
```
, including earlier picks in the sequence;
```
theirs
```
is the commit being applied.
Revert: infer nothing from the labels; compare current
```
HEAD
```
, the reverted commit, its selected parent, and the index stages.

Rebase：
```
ours
```
是基于新基准累积的rebase结果，包括已重放的commit；
```
theirs
```
是当前正在重放的commit。
Merge：
```
ours
```
是当前分支；
```
theirs
```
是正在合并的分支。
Cherry-pick：
```
ours
```
是当前
```
HEAD
```
，包括序列中较早的pick操作；
```
theirs
```
是正在应用的commit。
Revert：不要从标签推断任何信息；比较当前
```
HEAD
```
、被revert的commit、其选定的父commit以及索引阶段。

Safety

安全规则

Never use destructive resets, abort or quit an operation, skip or drop commits, overwrite unrelated changes, or change the requested history topology without explicit approval. If completion is unclear or unsafe, preserve the exact state and ask whether to provide resolution guidance, use the matching recovery command, or choose another integration strategy.

scripts/inspect-operation.sh

prints the active operation, current branch and commit, operation metadata, staged and conflicted paths, index stages, and marker locations.

未经明确批准，请勿使用破坏性的reset操作、中止或退出操作、跳过或丢弃commit、覆盖无关变更，或更改请求的历史拓扑结构。若完成操作的方式不明确或不安全，请保留当前精确状态，并询问用户是提供解决指导、使用匹配的恢复命令，还是选择其他集成策略。

scripts/inspect-operation.sh

会打印活跃操作、当前分支和commit、操作元数据、已暂存和冲突的路径、索引阶段以及标记位置。