企业官网建设流程全解析

1. 冲突的本质：两条时间线在这里交汇

很多人在用 Git 的时候，最怕看到的就是那串提示：CONFLICT (content)。一旦出现，第一反应往往是“完了，代码是不是被我搞坏了”，然后开始到处搜命令，找人问，或者干脆git reset --hard回到过去，把忙活半天的改动全扔掉。

先说结论：你会遇到冲突，不是因为你操作错误，也不是因为 Git 出了毛病，更不是你技术水平不行。你遇到冲突，仅仅意味着一个非常单纯的事实——在两条不同的分支上，同时有提交修改了同一个位置的内容，而 Git 不知道你想保留哪一边，所以它停下来问你。

我在实际带团队和做代码评审的时候发现一件很有意思的事：面对冲突时，情绪最稳定的，往往不是 Git 命令背得最熟的人，而是那些能在一分钟内说清楚“这条分支和那条分支分别改了什么、它们的共同祖先是谁、双方相对祖先各自动了哪些行”的人。换句话说，冲突解决的关键不是会敲哪条命令，而是能不能在脑子里还原出“同时发生了什么”。

这篇文章不打算只给你一套“遇到冲突怎么处理”的流程手册，而是想带着你把冲突这件事从底层逻辑到实际操作完整过一遍。读完你会明白：冲突标记里的每一段内容分别来自哪里、为什么 Git 有时候能自动合并有时候不能、merge 和 rebase 在解决冲突时到底有什么本质区别，以及那些让你头疼的“反复冲突”“合并完代码丢失”到底是怎么发生的。

如果你现在正好被某个冲突卡住，可以直接跳到第 4 部分看操作流程。但我的建议是，从第 2 部分开始顺着读，因为你只有理解了 Git 在冲突时看到的“三个人”，才能真正每次都在冲突现场做出正确的判断。

2. 冲突发生的瞬间，Git 眼里其实有三个人

2.1 先搞清楚三方合并是哪三方

要理解 Git 的冲突解决，第一步必须理解它采用的合并策略——三方合并（three-way merge）。这个名字听起来可能有点抽象，但拆开看其实非常简单。

假设你有一个项目，初始状态是一条主分支，文件里有一个函数：

def greet(name): return "Hello, " + name

某个时间点，你从主分支切了一条功能分支，准备给这个函数加一个默认参数。同时，你的同事在主分支上继续开发，把函数里的字符串从英文改成了中文。

这时候 Git 要干什么？它要把两条分支的改动合并到同一个目标上。但它不傻，它知道不能简单比较这两个版本的差异——因为两条分支都是从同一个初始状态分出来的，只要和初始状态一比，两边各自的改动清清楚楚。

这里的关键就出来了：三方合并里的“三方”，分别是最初的公共祖先版本（merge base）、当前分支版本（ours）和被合并分支版本（theirs）。

• 公共祖先版本：两条分支分道扬镳之前那个共同的提交。它是判断“谁改了什么”的基准。
• 当前分支版本：你正在工作的分支，在执行 merge 时用 HEAD 指向它。
• 被合并分支版本：你想合进来的那条分支上的最新提交。

Git 会比较这两个分支上各自相对公共祖先的改动。如果两边改的是完全不同的文件，或者同一文件的不同区域，它就自动把两边都保留下来。如果两边都改了同一文件的同一个区域，Git 就不知道该听谁的，于是标记为冲突，停下来让你做决策。

这个“以共同祖先为基准”的设计，就是 Git 合并能力的根基。很多旧的版本控制工具只有两个版本比较（two-way merge），效果差得多，因为它们不知道哪些改动是“新增”的、哪些改动是“修改”的，合并时非常容易把别人的改动覆盖掉。Git 之所以在合并方面明显强于 SVN 和 CVS，核心就是它引入了这个三方合并的概念。

为了帮你把这个模型在脑子里固定下来，你可以想象一个生活场景：你和室友合租。房东最初给客厅放了一张桌子（公共祖先）。你买了一把椅子放在桌边（你的改动），室友买了一个花瓶放在桌上（他的改动）。当你们都在家的时候，这些改动自然共存。但如果你们俩都买了椅子，都想放在桌边的同一个位置，这时候就没有一个客观标准能判断该放谁的——你俩必须自己商量。Git 的冲突就是这件事：不是它不能处理，是它没有资格替你决定。

2.2 哪些情况会冲突，哪些情况不会

理解了三方合并的模型，你就能预测哪些操作会冲突、哪些不会。这在实际工作中非常有用，能让你在操作前就心里有数。

不会冲突的情况：

两边改的是不同的文件。比如你在src/auth.ts里加了个函数，同事在docs/readme.md里更新了说明。合并时 Git 把两个文件的改动都直接保留，不打扰你。

两边改的是同一文件里完全不同的区域。你在文件头部加了一个 import，同事在文件尾部加了一个新函数。Git 能通过行号定位到这些改动互不重叠，自动合并。

一边改了文件，另一边完全没动这个文件。那更简单，直接把改动的版本拿过来就是。

一定会冲突的情况：

两边修改了同一个文件里的同一行内容。比如最初版本里有一行const userType = 'visitor'，你把它改成了'member'，同事把它改成了'admin'。Git 无法判断哪个才是正确的，于是冲突。

一边删除了一段代码，另一边修改了同一段代码。Git 不知道你是故意删掉的，还是不当心删掉的，也不知道同事的修改是否应该被保留，于是冲突。

两边都在同一个区域新增了内容，即使新增的内容恰好一模一样，部分 Git 版本也会报冲突（这种情况其实比较少见，可以手动处理）。

一个容易让人困惑的情况：二进制文件的冲突。因为二进制文件不像文本那样能按行比较，只要两边对同一个二进制文件（比如图片、编译产物）都做了改动，Git 几乎都会报冲突，而且冲突后没法直接手工编辑解决，通常只能二选一，或者让相关方重新生成一个新版本再提交。

顺带说一个我观察到的常见误解：很多人以为“我先 pull 再 push 就不会冲突”。这只是把冲突的时机从 push 转移到了 pull。因为 pull 本质上是 fetch + merge，你的本地改动和远端新提交同样会走三方合并流程，该冲突还是冲突。这不是你操作顺序的问题，而是两条时间线各自产生了改动，必然会交汇。

2.3 从两个具体的提交历史看“同时发生了什么”

光讲概念不够，我们来走一遍具体的提交历史。假设项目的提交线是这样：

A---B---C (main) \ D---E (feature/login)

初始提交是 A。从 A 之后，main 分支产生了两条线：主线一路走到 B、C，feature/login 切出来之后走了 D、E。现在你在 main 上执行git merge feature/login，Git 要做三方合并：

• 公共祖先：A
• 当前分支（ours）：C
• 被合并分支（theirs）：E

为什么公共祖先是 A 而不是 B？因为 feature/login 是从 A 这个提交上切出去的。虽然 main 分支上有 B 和 C，但它们之间是父子关系，对 feature/login 来说并没有关系。Git 找到的“分叉点”是 A。

现在假设 A 版本里config.js文件有一行：export const theme = 'light'。

• 在 C 上，这行被改成了export const theme = 'dark'。
• 在 E 上，这行被改成了export const theme = 'auto'。

两边相对 A 都在同一行做了修改，且修改结果不同，于是 Git 报了 content 冲突。

从 A 的角度看：C 分支的改动是“把 light 改成 dark”，E 分支的改动是“把 light 改成 auto”。Git 没有理由知道你想要哪一个，因为这两个改动都合法，改的是同一个起点。这就是“同时发生了什么”——不是“谁覆盖了谁”，而是“两边各自基于同一个旧版本，做出了互不相同的修改”。

理解了这一点，你就能明白为什么在冲突现场“责怪别人”是没有意义的。冲突不是代码污染，不是恶意覆盖，它就是正常的并行开发所形成的客观结果。

3. 冲突消息告诉我们什么：读懂 Git 在说什么

3.1 冲突标记的完整含义

当一个文件发生冲突，Git 会在文件内容里插入冲突标记。长这样：

<<<<<<< HEAD export const theme = 'dark'; ======= export const theme = 'auto'; >>>>>>> feature/login

很多初学者看到这堆尖括号就头皮发麻。但实际上，它的结构特别清晰，只要记住一个原则：从中间切割，左右各有一个提交的内容。

• <<<<<<< HEAD到=======之间的部分，是当前分支（HEAD）里的内容。在 merge 场景下，HEAD 就是你执行 merge 命令时所在的分支。在这一段里，我们看到的是export const theme = 'dark'，也就是 main 分支上的改动。
• =======到>>>>>>> feature/login之间的部分，是被合并分支上的内容。这里我们看到的是export const theme = 'auto'，即 feature/login 分支上的改动。
• >>>>>>> feature/login这行末尾的feature/login是告诉你对方分支的名字，方便你定位来源。

注意：如果是 rebase 场景，HEAD 方向的内容含义不同，我会在第 5 部分详细说。这里先记住 merge 场景下的方向就行。

解决冲突时，你要做的就是把<<<<<<< HEAD、=======、>>>>>>> feature/login这三行标记全部删除，然后把中间的内容改成你想要的结果。你可以只保留当前分支的改动、只保留对方分支的改动，也可以把两边的内容都融合在一起，甚至全部改成一个新版本。Git 只在乎一件事：这个文件里最终不要留下冲突标记。

可能有读者会有疑问：如果我只保留一边的内容，是不是就把另一边的改动丢了？答案是：不会丢。另一边分支的提交还在那个分支上，即便这次合并没合进来，你随时可以再 cherry-pick 或者手动补齐。不要怕“丢代码”，Git 的提交历史上记录了一切，怕的是你改完之后没确认内容就提交了。

3.2 同样的文件，Git 的提示信息为什么会不一样

有时候你会看到 Git 输出：

Auto-merging src/utils/format.ts CONFLICT (content): Merge conflict in src/utils/format.ts Automatic merge failed; fix conflicts and then commit the result.

这说明 Git 在自动合并阶段尝试合并src/utils/format.ts，但在内容层面遇到了冲突，合并流程暂停了。

有时候你会看到：

CONFLICT (modify/delete): src/legacy.ts deleted in feature/cleanup and modified in HEAD. Version HEAD of src/legacy.ts left in tree.

这叫 modify/delete 冲突：一个分支删除了文件，另一个分支修改了文件。Git 不知道你是希望保留文件（保留修改后的版本）还是随它删除（承认删除操作），所以停下来让你决定。这种冲突在解决方式上不太一样，你需要在 Git 里执行git add src/legacy.ts（保留修改版本）或者git rm src/legacy.ts（接受删除），而不是像 content 冲突那样编辑文件内容。

还有一种不常见但值得了解的提示是CONFLICT (add/add)：两个分支上各自新建了同名文件。Git 会同时保留两个版本，并在内容里标记冲突。这种场景通常意味着团队里没有做好分工，两个人各自在本地建了同名的文件。

看到这些不同的冲突类型时，不要慌。先确认冲突的类别，再决定处理策略。content 冲突靠编辑；modify/delete 冲突靠git add或git rm；add/add 冲突需要和对方确认哪个文件才是真正要保留的版本。

3.3 除了冲突标记，还要会看这些命令的输出

冲突发生后 Git 会切到一个“合并中”的状态。这时候第一步永远是搞清楚哪些文件有冲突。最直接的办法是git status，它会把冲突文件列在 Unmerged paths 下面，并且标注每个文件的冲突类型：

Unmerged paths: (use "git add <file>..." to mark resolution) both modified: src/utils/format.ts

both modified意思是双方都修改了这个文件，通常就是 content 冲突。如果看到deleted by them或deleted by us，则对应 modify/delete 冲突。

如果想快速查看哪些文件有冲突，还有一个更精炼的命令是git diff --name-only --diff-filter=U。U 表示 unmerged，列出的就是所有需要处理的冲突文件。在文件数量多的时候，这个输出比git status更干净。

再进一步，查看单个冲突文件的内容，用git diff。默认它会以合并后的差异形式展示，想看原始冲突标记，直接在编辑器里打开文件就行。我在实际操作中一般不太依赖git diff来看冲突内容，因为冲突标记在编辑器里颜色更清晰，上下文的视野也更完整。

但有一个命令对我来说是必备的：git log --merge。它会把正在合并的双方分支上那些可能导致冲突的提交列出来。当冲突文件很多、需要了解对方到底改了什么逻辑时，这个命令能很快帮你定位到具体是哪些提交改动了这些区域。相当于给了你一张“这次冲突涉及哪些历史”的清单。

4. 核心实操：手把手解决一次真正的冲突

4.1 最小复现案例：准备一个一定会冲突的场景

为了不让人看完理论还是不会操作，这里准备一个最小复现案例。你可以在本地随便建一个目录，按我的步骤走一遍，亲手制造一次冲突，再亲手解决它。

初始化仓库：

mkdir git-conflict-demo cd git-conflict-demo git init git config user.name "demo" git config user.email "demo@example.com"

创建初始文件greeting.py，内容如下：

def greet(name): return "Hello, " + name

提交初始版本：

git add greeting.py git commit -m "init: greet function"

从当前提交切出功能分支：

git checkout -b feature/theme

在 feature/theme 分支上，把greeting.py改成带默参数的形式：

def greet(name="world"): return "Hello, " + name

提交：

git commit -am "feat: add default name param"

切回主分支：

git checkout main

在主分支上，修改同一行，把字符串改成中文：

def greet(name): return "你好, " + name

提交：

git commit -am "i18n: greet in Chinese"

此时，执行合并：

git merge feature/theme

Git 会报冲突。打开greeting.py，你会看到类似这样的内容：

<<<<<<< HEAD def greet(name): return "你好, " + name ======= def greet(name="world"): return "Hello, " + name >>>>>>> feature/theme

这就是一次非常典型的 content 冲突。两边相对公共祖先（初始版本）都改了同一个函数的第一行，改法不一样。

4.2 解决冲突的三种典型策略

现在你面临选择：保留哪边的改动，还是两边都要。

策略一：只保留当前分支（HEAD）的改动。也就是不引入 feature/theme 上的修改。手动编辑，把冲突标记删掉，只留def greet(name):和中文 return 那行。最终文件长这样：

def greet(name): return "你好, " + name

这种选择适用于：对方分支的改动不重要、已经过时，或者你判断这次合并不应该把那个改动带进来。

策略二：只保留对方分支（feature/theme）的改动。最终文件：

def greet(name="world"): return "Hello, " + name

这种选择适用于：你发现自己分支上的改动才是多余的那个，对方分支的实现更合适。

策略三：综合两者。这是实践中最多的情况，也是最能体现“理解同时发生了什么”的策略。在这个例子中，两个改动其实不冲突——函数签名上想加默认参数，函数体里想改成中文问候。理想的合并结果是：

def greet(name="world"): return "你好, " + name

这就是“手动融合”的典型场景。冲突标记把两段内容并列摆在那，但并不意味着你只能二选一。你完全可以理解双方的意图之后，把它们自然地合并到同一个文件里。

在实际项目中，融合往往比二选一更常见。一个改了变量名，一个改了使用这个变量的函数，两边都有价值；一个新增了参数，一个用到了函数的新逻辑，合起来才是完整的业务功能。这也是为什么我反复强调，解决冲突的核心在于“理解”而不是“技巧”——你没有理解两边各自的意图，就不知道融合的正确姿势，只能机械地选一边，选完之后还可能把逻辑搞坏。

4.3 从冲突状态到完成合并的完整操作链

编辑完冲突文件之后，很多人会犯一个错误：直接把文件保存，然后立刻 commit。如果此时git status会提示你“All conflicts fixed but you are still merging”，意思是冲突已经手动解决了，但 Git 还没有记录这个“解决”的动作。

正确的完整流程是：

# 1. 把解决完冲突的文件标记为已解决 git add greeting.py # 2. 确认所有冲突都已处理（status 里没有 Unmerged paths 了） git status # 3. 提交合并结果 git commit -m "merge: merge feature/theme into main"

执行git commit之后，Git 会复用预先写好的 merge 提交信息，默认是Merge branch 'feature/theme' into main。你可以保留默认信息直接提交，也可以加上自己的说明。合并到此完成。

如果你在解决过程中发现越改越乱，希望放弃这次合并、恢复到合并前的状态，有两套方案：

• git merge --abort：如果合并还在进行中且尚未提交，这个命令会回到 merge 前的状态。
• git reset --hard HEAD：在合并被中断且你已经手动处理到一半时，这个命令能强制回到合并前的位置。但注意，这个命令会丢弃所有未提交的改动，包括你手动的编辑。

两个命令的区别一定要分清楚。git merge --abort是安全的，它只放弃合并相关的临时状态；git reset --hard会清掉工作区里所有非提交状态的内容，属于高危操作。新手没把握时，优先用git merge --abort。

还有一个小细节容易被忽略：当冲突文件很多、类型复杂时，建议按“从底层模块到上层入口”的顺序处理。因为往往是同一个函数被多处调用，先处理被调用的底层文件，再去处理调用方的冲突，思路会顺畅很多。反过来先处理上层文件，遇到底层逻辑冲突时可能要回炉重改。

4.4 不同场景下谁来“替你做决定”：merge 工具的使用

手动编辑冲突标记当然是万能的，但在文件多、冲突标记密集的时候，会非常累。这时候用可视化合并工具能显著提高效率。

VS Code 的合并编辑器是当前最推荐的选择。打开冲突文件后，在冲突标记位置会出现三路视图：左侧是当前分支版本，右侧是被合并分支版本，中间是最终合并结果。顶部会有一个按钮，可以一键选择“接受当前版本”“接受传入版本”或“接受组合版本”。

IDEA 内置的 Merge Revisions 工具同样很好用。它会以三栏形式展示 base、local（当前分支）、remote（被合并分支），你可以在中间的结果面板里直接编辑，每一处差异都能精确选择。

命令行党则可以用git mergetool，配合 Beyond Compare、Meld 这类外部工具。第一次使用需要配置：

git config --global merge.tool meld

不过这里有一点需要提醒：使用可视化工具不等于不用动脑手动调。很多工具的“接受组合版本”是机械地把两边内容拼接起来，并不保证拼接结果在逻辑上正确。我用这些工具的姿势是：用它们快速浏览所有冲突位置，把明显的二选一快速处理掉，把真正需要思考融合的冲突单独拿出来，用编辑器仔细改。

处理完所有冲突后，还是回到git add和git commit的流程。工具只是加速了冲突定位和初步处理，后续的验证和提交都必须你自己完成。

5. merge 与 rebase：冲突解决方式的本质差异

5.1 同样是冲突，位置的顺序反了

Git 里合并两条分支的改动有两种主要方式：git merge和git rebase。这两种方式下的冲突解决，表面上都是编辑冲突标记，但背后的“时间线逻辑”完全不同。经常有人在这上面栽跟头——在 rebase 过程中按照 merge 的处理思路，结果把提交顺序搞错了。

先看 merge。假设你有 main 和 feature/login 两条分支，公共祖先是 A，之后 main 走到 C，feature/login 走到 E。执行git merge feature/login时，Git 开一个额外的 merge 提交，把这两条线汇在一起。这个 merge 提交有两个父提交：main 的 C 和 feature/login 的 E。三方合并的基准是 A。

所以在 merge 冲突时，冲突标记里的<<<<<<< HEAD指向 main（你的当前分支），>>>>>>> feature/login指向即将被合入的分支。

再看 rebase。git rebase main在 feature/login 分支上执行的逻辑是：先把 feature/login 从公共祖先 A 之后的所有提交（D 和 E）临时保存下来，然后把 feature/login 基于的基点从 A 移动到 main 的最新提交 C，再把这些保存的提交逐个重放到 C 之上。

这个过程里，每个被重放的提交都会和主线上的新内容做一次三方合并。此时：

• 公共祖先变成了 main 分支的最新提交 C
• <<<<<<< HEAD指向的是 main 上的最新内容（也就是你已经 rebase 到的目标提交）
• >>>>>>> feature/login指向的是你正在重放的那个提交（也就是 feature/login 分支自己的改动）

发现没有？在 merge 时，HEAD 是你的分支，对方是别人的分支；在 rebase 时，HEAD 是目标主干，自己被重放的提交是“对方”。这个方向是反的。如果你习惯了 merge 场景下“HEAD 表示我的代码”，到 rebase 场景还用同一套逻辑去理解，就很容易把两边内容颠倒了。

举一个具体的例子。在 feature/login 分支上执行git rebase main，某个文件出现冲突，标记显示：

<<<<<<< HEAD const baseUrl = "https://api.example.com"; ======= const baseUrl = "https://staging-api.example.com"; >>>>>>> feature/login (add staging config)

在这个场景下，HEAD 段是 main 上已有的正式环境配置，feature/login 段是你自己的 staging 配置。如果你最终想要的是正式环境配置，就保留 HEAD 段；如果你需要的是 staging 配置，就保留你那段。这里不能机械地认为 HEAD 就是“我的”，必须对照改动来源去判断。

5.2 rebase 冲突为什么要一个个提交处理

merge 冲突时，你面对的是两个分支最终状态的差异，一次解决完所有冲突，提交一个 merge commit 就行。

rebase 冲突时，Git 是把你分支上的每个提交逐个重放。假设 feature/login 有 5 个提交，主线也有新的改动，那么 rebase 过程中最多可能发生 5 次冲突停顿。每次停顿都对应一个正在被重放的提交，解决完冲突后执行git add <file>，然后git rebase --continue，Git 会继续重放下一个提交。

这里有一个所有人都会踩的坑：在 rebase 冲突处理中，一旦某个提交被重放，它的提交者在多数情况下会变。如果你对某个被重放的提交做了大量修改，Git 会要求这次重放的提交信息和原始信息保持一致，可能需要你在--continue时重新写提交信息。

更麻烦的是，如果你在解决某个中间提交的冲突时，引入了不属于那个提交的改动，后续的提交可能会受到影响，导致冲突反复。比如你在第一个提交的冲突处理中，不小心把第二个提交将来要改的代码也一并改掉了，等 git 重放第二个提交时，它发现改动已经存在，要么提示空提交，要么再度冲突。

所以我的建议是：rebase 冲突不是一次性解决完所有冲突的，而是按提交逐个推进的。每个提交的冲突处理完、验证逻辑没问题，再 continue 到下一个。图省事想一口气改完所有冲突文件再 continue，在只有少数提交时也许可行，提交一多基本会出乱子。

在实际工作中，我的体会是：如果 feature/login 分支的提交数量很多（比如超过 10 个），主线又更新频繁，优先选择 merge，而不是 rebase。因为 rebase 的每个提交冲突处理成本是累加的，而 merge 是一次性处理双方最终差异。反过来，如果你希望保持提交历史的线性整洁（比如在开源项目里为了便于评审），或者需要把自己的修改基于最新主线上验证，再选择 rebase。

5.3 交互式 rebase 里的避坑：squash 和冲突的关系

很多人使用git rebase -i来合并小提交（squash），或者调整提交顺序。在交互式 rebase 中遇到冲突的概率比普通 rebase 更高，因为你在改变提交结构时，Git 需要重新计算每个提交的内容。

一个常见的错误操作是：在git rebase -i中，把两个都修改了同一个文件的提交 squash 成一个。如果这两个提交对同一处代码有不同修改，Git 会在这个 squash 过程中报冲突。这种冲突和 merge 冲突不同，它更像是“你过去自己的两个改动打架了”。

这种情况下，解决冲突的方式和普通 rebase 一样：编辑冲突标记、git add、git rebase --continue。要特别注意，squash 后提交信息不再是原来的多条，而是需要你编辑合并后的单条提交信息。如果冲突内容很多，说明这两个提交的改动本身就有重叠，需要考虑是否真的应该 squash，或者是否应该保留两个提交让历史更清晰。

交互式 rebase 是对提交历史的“手术”，操作前建议先用git branch backup-name留一个备份分支。万一 rebase 过程中出了不可收拾的问题，可以随时切回备份分支，重新再来。这个习惯我养成了很久，救过我好几次。

6. 高级场景与争议问题：当常规方案不够用

6.1 重复冲突：为什么同一个冲突总是一遍一遍出现

有一种情况比初次面对冲突更让人崩溃：你明明已经解决过某个冲突了，过几天合并分支时，同样的冲突又出现了，甚至在不同提交里反复出现。

我在实际项目里遇到过很多次。最常见的原因是解决冲突的提交没有正确包含到两个分支的共同路径上。举个例子：你在 main 上解决了与 feature/login 的冲突，做法是删掉 feature/login 里的某个函数，改成自己重新实现了一版。你的这个解决提交存在于 main 上。但是，feature/login 分支没有把 main 的这次解决合并回来。于是，等下次 feature/login 又要并入 main 时，Git 再次比较公共祖先时，发现 feature/login 上那个函数仍然存在，两边还是修改了同一区域，冲突再次出现。

解决这种问题的思路不是“再解一次冲突”，而是从根上消除分歧。你有两条路可以走：

• 把 main 合并进 feature/login（或者执行git rebase main），让 feature/login 也拿到 main 上的解决结果。这样一来，两边对同一个区域的认识就一致了，下次合并时就不会再冲突。
• 如果 feature/login 上的改动本身已经不需要了，直接在 feature/login 上删除相关改动并提交。

用一句话概括：冲突的根源是两边对同一区域有不同认知。要消灭重复冲突，就必须把“共识”同步到双方分支上。只在一侧解决，另一侧不知道，就会反复发生。

建议团队里定一个约定：当你在一个分支里解决了来自另一个分支的冲突时，尽快把这次解决合并回去，或者至少让相关方明确知晓这次变化的来龙去脉。否则，类似冲突会在未来某个时间点找上你。

6.2 合并后代码“消失”了？多半是这类问题

有一种让开发人员半夜惊醒的错误：合并完成后，代码能编过、测试能跑，但某个功能在线上就是不对劲，一查代码，某段逻辑没了。

这种“合并后代码丢失”的问题，多数不是因为 Git 的错误覆盖，而是来自三方合并的一个隐含行为：当一个分支上修改了某段代码，另一个分支上完全没动这段代码时，Git 会直接采用修改后的版本；反之，当一个分支删除了某段代码，另一个分支没动它时，Git 会把删除当作事实。

举个例子：你在一处较早的提交中，把某个函数的实现从 A 改成了 B。后来在另一个分支上开发时，无意中把包含这个函数的整个文件重置到了较早的状态。等到合并时，Git 看到一侧是“A 改成 B”，另一侧是“从 B 回到 A”，这其实是两个不同的改动，如果改动发生在同一区域且内容相反，就可能出现“看起来像是被删掉了”的结果。

还有一种常见情形是手滑使用了git checkout --ours或git checkout --theirs。在解决冲突时，这两个命令可以快速将文件替换为当前分支或被合并分支的版本。但如果你的目标是“融合两边”，却错用了这两个命令整文件覆盖，另一边分支的改动就全部丢失了。它们可以用于快速处理明显的二选一，但要谨慎使用，务必先git diff确认文件内容再决定。

规避合并后代码丢失的最有效方法，不是靠小心，而是靠合并完成后的验证。我在实践中会做三件事：

1. 合并提交后先用git diff HEAD^1 HEAD --stat和git diff HEAD^2 HEAD --stat检查合并结果相对两侧父提交的差异。看到异常多的文件变化时，主动确认是不是覆盖错了。
2. 运行一次完整的构建和关键测试。很多问题在编译或测试阶段会暴露，尤其是测试断言对函数返回值敏感的代码路径。
3. 和相关的同事一起过一遍被合并的改动。如果这个问题影响业务逻辑，最好让熟悉那块代码的人都确认一遍，别省这一步。

记住，Git 的提交历史永远不会骗你，但人可能会读错历史。合并后代码丢失通常都是操作者没有看清两侧分支的相对变化，被自动合并的行为骗过去了。

6.3 不需要写很多命令的“黄金守则”

如果你要问我，团队里到底应该怎么做才能减少冲突、解决冲突时又稳又快，我会把下面几条当成不可妥协的底线：

• 保持分支的生命周期短。功能分支不要开太久，越晚合并，冲突的可能性越大，成本也越高。理想情况下，一个功能分支应该在几天内合并回主干。
• 小步提交，频繁同步。不要把一大堆互不相关的改动攒在一个分支里。一个提交只做一件事，并且在开发过程中定期把主干的最新改动合并进自己的分支，让同步成为常态，而不是最后合并时的突发事件。
• 处理冲突前先看历史。用git log --oneline --graph和git log --merge搞清楚两边各自做了什么。这比你直接打开文件猜要可靠得多。
• 解决冲突后，先运行测试再提交。冲突解决得对不对，不能靠“看着好像没问题”来决定，得靠测试来验证。
• 对不确定的冲突，找相关同事一起确认。不要自己默默做决定，尤其当冲突涉及核心业务逻辑时。

这几条看着简单，但很多团队做不到。真正拉低效率的，往往不是冲突本身，而是冲突发生时团队没有一个共同理解的分歧消解机制。

7. 常见问题速查表和排查技巧

下面这张表整理的是我这些年遇到最多的问题，以及对应的排查路径。把它存下来，下次碰到类似的场景，对着走一遍就能少走很多弯路。

再补充一个排查小技巧：当你在一个冲突文件里同时看到多处冲突标记，且不确定哪些改动和哪些提交相关时，可以用git log -p <file>查看这个文件的完整修改历史。这个命令会列出每个提交对这个文件做了什么改动，看到具体改动时间点和提交说明后，往往就能推断出哪一版才是正确的。

还有一种情况：你在处理冲突时改了文件，但保存后发现 Git 仍然提示冲突未解决。这通常是因为文件里还有残留的冲突标记——你没有把某一段<<<<<<<、=======或>>>>>>>删干净。这时候直接搜索这些符号即可。在很多编辑器中，用>>>或<<<搜索会更快，因为正常的业务代码里极少出现这种连续尖括号。

8. 冲突解决后的提交信息与验证：别让最后一步坏了前面的功夫

冲突解决完之后，很多人以为 commit 完就结束了，但真正专业的做法还差两个环节。

第一，提交信息里要写清楚这次合并做了什么。默认的 merge 提交信息只有 “Merge branch 'xxx' into yyy”，这对后续查看历史的人来说帮助有限。如果你在解决冲突时做了关键决策（比如“保留 featureA 的认证逻辑，去掉 featureB 的旧配置”），建议在提交信息里用一段话说明。这不是为了形式，而是几个月后你回溯问题时，这行字可能是唯一的线索。

第二，必须验证构建和测试。我把这一步看得比解决冲突本身还重要。因为冲突解决后，即使代码语法没错、可以提交，逻辑上也可能完全不对。尤其当你选择了“融合双方”的方式时，两段代码拼在一起是否能正常工作，必须由测试来回答。不跑测试就提交，等于把自己的猜测当成事实交付。

具体验证步骤：本地跑一次构建，把所有相关的单元测试和集成测试跑一遍，确认关键场景没有回归。如果项目有 CI，尽快推送合并结果，让 CI 在干净环境里完整跑一遍。

另外，验证完成后建议顺手用git log --graph --oneline看一下合并后的提交结构。如果你做的是 merge，应该能看到两条分支汇合形成的分叉节点；如果你做的是 rebase，应该是一条干净的线性历史。这个检查能帮你确认你实际操作的是 merge 还是 rebase，避免自以为做了 merge，实际上因为操作顺序问题产生了意外历史。

9. 我的一次真实经历：从“不敢合并”到“主动解决”

说一件让我对冲突彻底改观的事。

几年前我接了一个跨模块的重构任务，需要同时改动几个核心模块的打点逻辑。当时团队节奏快，我们开了个功能分支，我改自己的部分，另一个同事改依赖这些模块的新页面。因为交叉文件太多，每次合并主干进来都是一堆冲突。最开始那几天，我每次看到 CONFLICT 都特别慌，第一反应就是找人求助，或者干脆把冲突文件 refetch 出来重新改一遍。

直到有一天，我在处理一个反复出现的冲突时，花了几分钟静下心来看双方的改动。不看不知道，一看才发现，我重构逻辑时顺手把入口函数的参数顺序改了，而同事的新页面正是按照旧参数顺序在调用的。这个冲突其实非常清晰地告诉我：两边对同一个接口的认知已经不一致了。这时候光是编辑冲突标记没有意义，我必须主动去协调“接口应该长什么样”这个问题。

于是我找到同事，确认了新参数顺序是重构的一部分，同事那边也理解了原因，把页面调用更新了。那次之后，同样的冲突再也没出现过。

这件事给我的启发是：冲突解决的价值，不在于你所记住的命令行，而在于你愿不愿意去理解“两条分支各自做了什么、为什么会做成这样”。命令只是工具，决策才是目标。有时候一次冲突解决得好，背后是对接口设计、代码职责、模块边界的重新审视，这些问题搞清楚了，冲突自然就消失了。

现在我教别人处理 Git 冲突时，很少只教命令，而是先问三个问题：这个冲突发生在哪个文件？双方各自改了什么？哪一边的改动才符合当前业务的目标？把这三个问题答清楚，操作步骤也就是git add和git commit那点事。

最后再分享一个小技巧。如果你经常要在多个分支之间合并、拉取，建议给 Git 配置一个默认的 diff 工具和 merge 工具，同时设置好merge.conflictStyle。我个人比较推荐diff3风格的冲突展示，它会在冲突标记里额外显示公共祖先版本的内容。对于理解“同时发生了什么”非常有帮助——你一眼就能看出双方各自相对祖先进了哪些改动。

git config --global merge.conflictStyle diff3

配置之后，冲突标记会变成三段式，比默认的两段式多了中间一部分公共祖先的内容。这样处理冲突时，你手上多了一个重要的参考信息，决策的底气也会足很多。

希望这篇文章能帮你在下一次遇到冲突时，少一点慌张，多一点“让我看看这里到底发生了什么”的好奇心。毕竟，好奇心才是解决一切技术问题最好的起点。