程序员如何用 Git 处理分支冲突并保留正确改动

Git 报出冲突，不代表代码已经丢失，也不代表它知道哪一边才是“正确”的。冲突说明 Git 无法依据共同祖先和两边的改动，自动确定最终内容。此时需要开发者判断目标行为，手动整理文件，再检查和测试结果。

处理冲突的关键不是机械地选择当前分支或另一个分支，而是先弄清楚操作背景、每一边改动的目的，以及最终版本应满足什么要求。下面从常见场景、冲突识别、具体操作、验证和撤销几个方面说明。

一、什么情况下会遇到分支冲突

假设主分支上的函数与功能分支上的同一段代码都发生了变化。合并时，Git 会尝试把两边的修改与共同祖先版本结合起来。如果修改范围没有重叠，通常可以自动合并；如果同一行被不同方式修改，Git 就无法替你判断，因而暂停操作并标记冲突。

常见触发场景包括：

• 合并分支：执行 git merge，把其他分支合入当前分支。
• 变基：执行 git rebase，将当前分支上的提交逐个重放到新基底上。
• 拣选提交：执行 git cherry-pick，将某个提交应用到当前分支。
• 拉取远端更新：git pull 通常会先获取远端提交，再根据配置执行合并或变基，因此也可能遇到冲突。

冲突不只发生在普通文本的同一行。一个分支删除了文件、另一个分支修改了它，可能形成“删除/修改”冲突；双方重命名同一文件、目录结构发生变化，也可能需要手动判断。二进制文件通常无法像文本一样逐行合并，需要选择某个版本或用专门工具处理。

二、开始处理前，先确认操作背景

不要在不清楚当前状态时连续尝试 merge、rebase、reset 等命令。先查看状态和分支：

git status
git branch --show-current
git log --oneline --graph --decorate -12

git status 会指出正在进行的操作，例如合并中、变基中或拣选提交中，并列出未解决的路径。发生冲突时，相关文件通常显示为 both modified、deleted by us 等状态。具体提示会因冲突类型和 Git 版本略有差异。

如果工作区在操作开始前就有未提交修改，尤其要先确认哪些修改属于原有工作、哪些来自正在进行的集成操作。Git 一般会在本地改动可能被覆盖时阻止部分操作，但不能把这当成备份机制。重要改动应先提交到合适的临时分支，或用其他可靠方式保存；不要为了清理状态而随手运行会丢弃内容的命令。

尤其要记住：git reset --hard 会让当前分支和工作区重置到指定提交，可能丢弃未提交修改；git clean 可以删除未跟踪文件。处理冲突时通常不需要这两条命令。

三、识别冲突标记及其含义

文本冲突文件中可能出现这样的内容：

<<<<<<< HEAD
当前分支的内容
=======
准备合入的分支内容
>>>>>>> feature/login

在普通的合并冲突中，开头标记之后到分隔线之前是当前分支一侧的内容；分隔线之后到结尾标记之前是正在合入的一侧内容。冲突文件中的这些标记不是有效业务代码，最终文件里必须清理掉。你可以保留任一侧，也可以结合两边内容重新编写，结果不必等同于其中某一方。

如果使用了带共同祖先信息的冲突标记，还可能看到 ||||||| 段落，它展示共同祖先版本，有助于理解双方分别改了什么。是否显示这一段取决于相关配置和操作方式。

要查看所有尚未解决的路径，可以运行：

git diff --name-only --diff-filter=U
git status

对于文本冲突，git diff 可以检查未解决内容；git diff --cc 可用合并差异的形式查看冲突周围的变化：

git diff --cc

更底层地查看索引中的冲突条目，可运行：

git ls-files -u

未解决的冲突路径通常在索引中有多个阶段的条目，常见的是阶段 1（共同祖先）、阶段 2（ours）和阶段 3（theirs）。这有助于诊断，但不要求每次都手动操作索引。大多数情况下，直接编辑工作区文件，再用 git add 标记解决即可。

四、可靠的处理流程：理解、编辑、验证、标记

1. 逐个查看冲突文件

不要看到冲突就全选一侧。先读完整函数、配置段或文档上下文，再结合相关提交、需求说明和测试判断双方改动的意图。可以用下面的命令查看提交历史：

git log --oneline -- path/to/file
git show <commit> -- path/to/file

把 <commit> 换成实际提交哈希或引用。理解“为什么这样改”往往比只看冲突区的几行更重要：一侧可能修复了边界条件，另一侧可能加入了新接口，两项改动不一定互斥。

2. 编辑出最终版本

打开冲突文件，删除冲突标记，并按目标行为整理内容。例如，两个分支分别增加了校验和日志，可能应该同时保留。处理后要确认括号、缩进、导入、配置格式等结构没有被破坏。

冲突标记有时会被代码编辑器自动隐藏或提供按钮，但按钮名称不等于业务判断。“接受当前”“接受传入”之类选项只是在文件内容上选择一边，不会自动保证代码正确。点击之前应先知道按钮对应哪一侧，并检查被丢弃的改动是否确实不需要。

3. 标记文件已解决

编辑完后，使用 git add 将解决后的文件加入索引：

git add path/to/file

这里的 git add 不只是“保存文件”，也表示告诉 Git：这个路径的冲突已由我处理，当前工作区内容是要采用的版本。若误将仍带有冲突标记的文件加入索引，Git 通常不会判断业务内容是否正确，因此还要主动检查。

如果删除该文件是正确结果，则确认删除后可以用 git rm path/to/file 更新索引。对删除/修改冲突，不应只因为一侧删了文件就直接保留删除；需要判断删除是否仍符合当前需求。

4. 检查剩余冲突和最终差异

逐个解决文件后运行：

git status
git diff --check
git diff --cached

git diff --check 会检查差异中的空白问题，例如行尾多余空格；它不是语法检查，也不能证明行为正确。git diff --cached 查看已经暂存、即将作为解决结果提交的改动。确认内容和文件清单都符合预期，再运行项目测试、静态检查或构建命令。

五、完整示例：合并功能分支时保留两边的正确改动

假设项目有一个简单的 Python 函数，主分支添加了空值校验，功能分支添加了长度限制，两边都修改了同一函数。下面的命令可以在一个临时目录中建立示例仓库并制造冲突。示例使用 Bash 风格命令，适用于常见 Unix shell；其他环境可以按顺序手动创建文件和目录。

mkdir git-conflict-demo
cd git-conflict-demo
git init
git config user.name "Demo User"
git config user.email "[email protected]"

cat > validator.py <<'EOF'
def validate_name(name):
    return name.strip()
EOF

git add validator.py
git commit -m "Add initial validator"
git branch -M main

git switch -c feature/max-length
cat > validator.py <<'EOF'
def validate_name(name):
    name = name.strip()
    if len(name) > 20:
        raise ValueError("name too long")
    return name
EOF
git add validator.py
git commit -m "Limit name length"

git switch main
cat > validator.py <<'EOF'
def validate_name(name):
    if name is None:
        raise ValueError("name is required")
    return name.strip()
EOF
git add validator.py
git commit -m "Reject missing name"

git merge feature/max-length

最后一条命令会因两边修改同一段内容而产生冲突。运行 git status 后，可以看到 validator.py 未解决。文件中会出现类似这样的标记：

<<<<<<< HEAD
def validate_name(name):
    if name is None:
        raise ValueError("name is required")
    return name.strip()
=======
def validate_name(name):
    name = name.strip()
    if len(name) > 20:
        raise ValueError("name too long")
    return name
>>>>>>> feature/max-length

如果需求是既拒绝 None，又限制去除首尾空格后的名称长度，可以把文件整理为：

def validate_name(name):
    if name is None:
        raise ValueError("name is required")

    name = name.strip()
    if len(name) > 20:
        raise ValueError("name too long")

    return name

在这个结果中，两边的改动都被保留，并且长度检查针对去空格后的值。随后暂存并检查：

git add validator.py
git status
git diff --cached
git diff --check

项目有测试时应运行对应测试。为了让示例可直接验证，也可以执行下面的 Python 命令：

python -c "from validator import validate_name; assert validate_name(' Ada ') == 'Ada'; exec(\"try:\\n validate_name(None)\\nexcept ValueError:\\n pass\\nelse:\\n raise AssertionError('None accepted')\"); exec(\"try:\\n validate_name('x' * 21)\\nexcept ValueError:\\n pass\\nelse:\\n raise AssertionError('long name accepted')\")"

确认解决结果后，完成合并提交：

git commit -m "Merge feature/max-length"

常规的非快进合并在冲突解决后通常需要创建合并提交；如果合并操作是快进则不会有冲突。是否自动生成提交信息、提交信息如何编辑，可能受命令选项和配置影响。

六、ours 和 theirs：不是业务上的正确与错误

Git 提供了接受某一侧文件内容的快捷方式。例如，合并进行中，可以用以下命令让冲突文件采用当前分支一侧，或采用正在合入一侧：

git checkout --ours -- path/to/file
git checkout --theirs -- path/to/file

较新的 Git 也可以用 git restore 表达相同用途：

git restore --ours -- path/to/file
git restore --theirs -- path/to/file

这些命令会把相应一侧的文件内容写入工作区；它们不是把“正确版本”自动挑出来的智能合并器，也不应在没有确认的情况下用于一批重要文件。执行后仍需检查结果，并使用 git add 标记冲突已解决。

最容易混淆的是：ours 和 theirs 的含义取决于当前操作。普通合并时，ours 通常是当前检出的分支，theirs 是被合入的分支。但在变基过程中，Git 会把当前提交逐个重放到新基底上；重放时的“ours”通常指新基底一侧，“theirs”通常指正在重放的提交一侧。因此，不能仅凭“我的分支是 feature”就推断 --ours 一定代表 feature 内容。

对变基冲突，建议依据 git status、冲突文件内容和当前重放的提交进行判断，而不是批量运行 git checkout --ours . 或 git checkout --theirs .。后者可能把整棵工作树中多个文件的改动都覆盖掉。

七、删除、重命名和二进制冲突怎么处理

删除与修改同时发生

一种分支删除文件，另一种分支修改文件时，先确认删除是否是有意的。若文件仍需存在，应检查修改版本并恢复它；若删除已被需求取代，则确认工作区和索引中的最终状态确实是删除。不要因为 Git 提示冲突就随意保留文件或删除文件。

重命名冲突

两个分支可能把同一文件改成不同名称，或一个分支移动文件、另一个分支继续修改原路径。Git 对重命名的判断依据文件内容相似度等因素，最终提示不一定直观。检查 git status 和相关路径，确定最终应留下的路径，再检查内容是否包含双方需要的修改。

二进制文件冲突

图片、压缩包、部分办公文档等通常不能通过文本冲突标记进行逐行合并。需要根据项目约定选择一侧版本，或者使用相应应用程序、资产合并工具处理。解决后同样要检查最终文件，并暂存正确路径。不要把文本文件的 ours/theirs 操作当作通用的内容合并能力。

八、合并、变基与拣选提交的收尾方式

解决冲突后应根据当前进行的操作完成收尾，不能只看冲突标记已经消失就认为任务结束。

• 合并：解决冲突、暂存文件、检查差异并测试，然后运行 git commit 完成合并；如果使用了特定选项或工具，应按其提示确认操作状态。
• 变基：解决当前提交引起的冲突，暂存解决文件，再运行 git rebase --continue。如果后续提交再次产生冲突，需要重复处理。需要放弃整个变基时，运行 git rebase --abort。
• 拣选提交：解决冲突并暂存后，通常运行 git cherry-pick --continue。放弃当前拣选操作可运行 git cherry-pick --abort。

对于合并操作，放弃本次合并可运行：

git merge --abort

--abort 的目标是结束相应的进行中操作并尽量恢复到操作开始前的状态。若开始操作前已经存在未提交修改，或手动改动了相关文件，恢复结果可能与预期不同。Git 也可能无法无损恢复某些复杂情形，因此操作前保存重要工作仍然必要。

如果只是想查看冲突，不确定如何继续，可以先停止操作并向团队确认流程；不要用强制重置来代替理解当前状态。对于已经解决、但尚未提交的冲突，也可以继续检查和修正，必要时重新暂存。

九、常见错误及其原因

1. 不看内容，直接选择一侧

这样可能丢掉另一边的必要修复，或把已经过时的逻辑带入目标分支。快捷选择只能减少编辑工作，不能代替需求判断。

2. 只删除冲突标记，不检查逻辑

冲突标记消失，只说明文本里没有这些标记；它不证明控制流正确、配置有效或测试通过。合并后的逻辑可能需要重新组织，而不是把两段代码简单拼接。

3. 冲突文件改完后忘记暂存

解决结果只有在对应路径被暂存后，Git 才会把它记录为已解决。忘记运行 git add，继续操作时 Git 仍会认为冲突未处理。

4. 看到 git status 变干净就认定代码正确

Git 的状态只描述工作区和索引相对提交的情况，不会验证业务规则。冲突处理后要检查差异、运行测试，并在需要时进行人工审查。

5. 在变基时误解 ours 和 theirs

变基是在新基底上重放提交，角色含义容易与直觉相反。先辨认当前正在重放的提交和目标基底，不要按分支名字猜测。

6. 用 git add . 一次性标记所有内容

这可能把与本次解决无关的修改、临时文件或错误版本一并加入索引。冲突较多时，应先查看 git status，按路径暂存，再检查 git diff --cached。

7. 把 Git 冲突处理当作权限或安全验证

Git 合并解决的是版本内容如何组合，不会检查代码是否安全，也不会验证数据是否可信。含有密钥、凭据或敏感配置时，应遵循项目的秘密管理流程；冲突解决本身不能替代密钥轮换、访问控制或安全审查。

十、减少冲突的实用做法

• 缩小分支差异：定期同步团队约定的基分支，避免积累大量彼此重叠的修改。同步前确认团队采用合并还是变基策略。
• 保持提交聚焦：一个提交尽量解决一个明确问题，便于比较、回退和追溯冲突来源。
• 避免多人长期编辑同一大片文件：可以通过模块拆分、明确接口和提前沟通减少内容重叠。
• 提交前运行检查：测试无法消除冲突，但能帮助发现解决后引入的语法、行为和格式问题。
• 使用 git rerere 时保持审查：该功能可以记录并复用之前的冲突解决结果，适合反复合并同类变更的场景。但它复用的是历史解决方案，不会理解当前需求；复用后仍要检查文件、差异和测试结果。可以用 git config rerere.enabled true 在当前仓库启用，再根据团队要求评估配置。

十一、冲突处理的检查清单

在结束一次合并、变基或拣选提交前，可以逐项确认：

• 我是否知道当前执行的是合并、变基还是拣选提交？
• 每个冲突文件的双方改动意图是否清楚？是否需要同时保留两边的行为？
• 最终文件是否已移除冲突标记，并保留了正确的文件路径和内容？
• 所有冲突路径是否已经暂存，是否还有未解决文件？
• git diff --cached 是否只包含预期内容？
• 项目测试、构建或必要的人工审查是否通过？
• 收尾命令是否与当前操作匹配：合并提交、git rebase --continue，或 git cherry-pick --continue？

Git 冲突的本质是自动合并无法替人判断改动意图。可靠做法是先确认操作状态，再理解双方修改，编辑出符合需求的最终版本，暂存后审查差异并运行验证。把这几个步骤落实到日常工作中，冲突就不再是需要靠“选一边”碰运气的问题，而是一个可以检查、解释和安全收尾的代码集成过程。