界面已本地化;技能介绍与说明文档按所选语言由 AI 自动翻译,代码、命令、路径和专业术语保留原文,以原作者文档为准。
探索技能
开发与工程 · SKILL.md

resolve-git-conflicts

resolve-git-conflicts

【开发与工程】使用安全的恢复策略解决合并和变基冲突。涵盖识别冲突来源、读取冲突标记、 选择解决策略,以及安全地继续或中止操作。适用于 git merge、rebase、 cherry-pick 或 stash pop 报告冲突、git pull 导致更改冲突,或需要安全 中止并重新开始失败的合并或变基操作。

独立 GitHub 快照 · 自动分类 · 以原作者文档为准

技能说明

GitHub

name: resolve-git-conflicts description: > 使用安全的恢复策略解决合并和变基冲突。涵盖识别冲突来源、读取冲突标记、 选择解决策略,以及安全地继续或中止操作。适用于 git merge、rebase、 cherry-pick 或 stash pop 报告冲突、git pull 导致更改冲突,或需要安全 中止并重新开始失败的合并或变基操作。 locale: zh-CN source_locale: en source_commit: 6f65f316 fence_basis_commit: 6f65f316 translator: claude-sonnet-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: git complexity: intermediate language: multi tags: git, merge-conflicts, rebase, conflict-resolution, version-control

解决 Git 冲突

识别、解决并从合并和变基冲突中恢复。

适用场景

  • git merge 或 git rebase 报告冲突
  • git cherry-pick 无法干净应用
  • git pull 导致更改冲突
  • git stash pop 与当前工作区冲突

输入

  • 必需:存在活跃冲突的仓库
  • 可选:首选解决策略(ours、theirs、手动)
  • 可选:关于哪些更改应优先的上下文信息

步骤

第 1 步:识别冲突来源

确定引起冲突的操作:

# Check current status
git status

# Look for indicators:
# "You have unmerged paths" — merge conflict
# "rebase in progress" — rebase conflict
# "cherry-pick in progress" — cherry-pick conflict

状态输出会告知哪些文件存在冲突以及当前进行中的操作。

预期结果: git status 显示列在"Unmerged paths"下的文件,并指示当前活跃的操作。

失败处理: 若 git status 显示工作区干净但预期存在冲突,则操作可能已完成或已中止。检查 git log 查看近期活动。

第 2 步:读取冲突标记

打开每个冲突文件,定位冲突标记:

<<<<<<< HEAD
// Your current branch's version
const result = calculateWeightedMean(data, weights);
=======
// Incoming branch's version
const result = computeWeightedAverage(data, weights);
>>>>>>> feature/rename-functions
  • <<<<<<< HEAD 到 =======:当前分支的版本(或正在变基到的分支)
  • ======= 到 >>>>>>>:传入的更改(被合并的分支或正在应用的提交)

预期结果: 每个冲突文件包含一个或多个带有 <<<<<<<、======= 和 >>>>>>> 标记的块。

失败处理: 若未找到标记但文件显示为冲突,可能是二进制文件冲突或"已删除 vs 已修改"冲突。使用 git diff --name-only --diff-filter=U 查看完整冲突列表。

第 3 步:选择解决策略

手动合并(最常用):编辑文件以逻辑方式合并两侧更改,然后删除所有冲突标记。

采用我方(保留当前分支版本):

# For a single file
git checkout --ours path/to/file.R
git add path/to/file.R

# For all conflicts
git checkout --ours .
git add -A

采用对方(保留传入分支版本):

# For a single file
git checkout --theirs path/to/file.R
git add path/to/file.R

# For all conflicts
git checkout --theirs .
git add -A

预期结果: 解决后,文件包含正确的合并内容,不残留任何冲突标记。

失败处理: 若选择了错误的一侧,可从合并基础重新读取冲突版本。在合并过程中,git checkout -m path/to/file 会重新创建冲突标记,让你重新尝试。

第 4 步:将文件标记为已解决

编辑完每个冲突文件后:

# Stage the resolved file
git add path/to/resolved-file.R

# Check remaining conflicts
git status

对"Unmerged paths"下列出的每个文件重复此操作。

预期结果: 所有文件从"Unmerged paths"移动到"Changes to be committed",任何文件中均不残留冲突标记。

失败处理: 若 git add 失败或标记仍然存在,请重新打开文件,确保所有 <<<<<<<、======= 和 >>>>>>> 行已被删除。

第 5 步:继续操作

所有冲突解决后:

合并操作:

git commit
# Git auto-populates the merge commit message

变基操作:

git rebase --continue
# May encounter more conflicts on subsequent commits — repeat steps 2-4

cherry-pick 操作:

git cherry-pick --continue

stash pop 操作:

# Stash pop conflicts don't need a continue — just commit or reset
git add .
git commit -m "Apply stashed changes with conflict resolution"

预期结果: 操作完成,git status 显示干净的工作区(或在 rebase 过程中移至下一个提交)。

失败处理: 若 continue 命令失败,检查 git status 查看剩余未解决的文件。所有冲突必须解决后才能继续。

第 6 步:必要时中止操作

若解决过于复杂或选择了错误的方法,可安全中止:

# Abort merge
git merge --abort

# Abort rebase
git rebase --abort

# Abort cherry-pick
git cherry-pick --abort

预期结果: 仓库恢复到操作开始前的状态,无数据丢失。

失败处理: 若中止失败(罕见情况),使用 git reflog 找到操作前的提交,并通过 git reset --hard <commit> 恢复。谨慎使用——此操作会丢弃未提交的更改。

第 7 步:验证解决结果

操作完成后:

# Verify clean working tree
git status

# Check that the merge/rebase result is correct
git log --oneline -5
git diff HEAD~1

# Run tests to confirm nothing is broken
# (language-specific: devtools::test(), npm test, cargo test, etc.)

预期结果: 工作区干净,合并历史正确,测试通过。

失败处理: 若解决后测试失败,合并可能引入了逻辑错误,即使语法冲突已解决。请仔细审查差异并修复。

验证清单

  • 所有文件中均不残留冲突标记(<<<<<<<、=======、>>>>>>>)
  • git status 显示干净的工作区
  • git log 中的合并/变基历史正确
  • 冲突解决后测试通过
  • 未引入意外的更改

常见问题

  • 盲目采用一侧:--ours 或 --theirs 会完全丢弃另一侧。仅在确定某个版本完全正确时使用。
  • 代码中残留冲突标记:编辑后始终搜索整个文件中的残留标记。部分解决会导致代码损坏。
  • 变基过程中修改提交:在交互式变基过程中,除非变基步骤明确要求,否则不要使用 --amend。改用 git rebase --continue。
  • 中止时丢失工作:git rebase --abort 和 git merge --abort 会丢弃所有解决工作。仅在想重新开始时才中止。
  • 解决后不运行测试:语法上干净的合并仍可能在逻辑上有误。始终运行测试。
  • 变基后强制推送:变基共享分支后,强制推送前请与协作者沟通,因为这会重写历史。

相关技能

  • commit-changes — 冲突解决后的提交
  • manage-git-branches — 导致冲突的分支工作流
  • configure-git-repository — 仓库设置与合并策略
我的收藏