git 要解决的冲突，是由分支合并带来的。

合并（Merge）是将分支 A 的更改合并到分支 B 的过程。

合并场景

假如我们有 master 分支，然后有基于 master 分支创建出来的 develop 分支。

从 develop 分支合并到 master 分支的场景有以下两种情况：

• develop 有修改但 master 没有。

• develop 有修改且 master 有修改。

合并冲突发生在上述的第二个场景里，当同一个文件在两个分支上都被修改了。

• 同一文件的同一部分被不同的分支修改：当两个或多个分支对同一文件的同一部分进行了不同的修改时，Git 无法自动合并这些更改，从而产生冲突。

• 如果一个分支删除了某个文件，而另一个分支修改了同一个文件，Git 也会产生冲突。

• 当一个分支重命名了某个文件，而另一个分支对该文件进行了修改，Git 也会产生冲突。

出现冲突的时候，就需要手动解决冲突并提交合并结果。

合并的类型

合并的结果有两种，一是直接合并，不产生新的提交。二是有冲突并解决了冲突，它会产生新的提交，这里的提交内容就是合并冲突修改。

这里有三种类型的合并：前进合并（fast-ford）、三方合并（three-way merge）和变基合并（Rebase）。

快速前进合并（fast-forward）是最简单的合并方式。

还是以上述 master 分支和 develop 分支为例来说明。

当 master 分支没有新的提交时，Git 只需将 master 分支的指针移动到 develop 分支的最新提交即可。这种合并不会产生新的合并提交。

三方合并（three-way merge）是指当 master 分支和 develop 分支都有新的提交时，Git 会进行三方合并。

这种合并会创建一个新的合并提交，包含两个分支的更改。

# 切换到目标master分支 git checkout master  # 合并源develop分支 git merge develop 

变基合并（Rebase）是将 develop 分支的提交应用到 master 分支的基础上，从而避免创建合并提交。

这种方式可以保持提交历史的线性，但可能会导致冲突需要手动解决。

# 切换到源develop分支 git checkout develop  # 变基到目标master分支 git rebase master 

合并策略

在进行合并时，还能使用不同的合并策略来控制合并的行为。

常见的合并策略包括：

• 默认策略（recursive）：这是 Git 的默认合并策略，适用于绝大多数情况。

• 合并策略选项（ours/theirs）：在冲突时，选择保留当前分支或合并分支的更改。

# 使用 ours 策略进行合并 git merge -s ours develop 

解决合并冲突的办法

解决合并冲突需要手动干预，基本上可以按以下步骤进行：

• 查看冲突文件

当合并冲突发生时，Git 会提示哪些文件存在冲突。可以使用 git status 命令查看冲突文件。

git status 

• 打开冲突文件

打开冲突文件，可以看到冲突部分被标记为 <<<<<<< HEAD、======= 和 >>>>>>> branch_name。

这些标记分别表示当前分支的更改、分隔符和合并分支的更改。

<<<<<<< HEAD 当前分支的更改 ======= 合并分支的更改 >>>>>>> branch_name 

• 手动解决冲突

根据实际情况，手动编辑冲突文件，保留需要的更改并删除冲突标记。

保留的更改 

• 标记冲突已解决

解决冲突后，使用 git add 命令将修改后的文件添加到暂存区。

git add conflict_file 

• 提交合并结果

最后，使用 git commit 命令提交合并结果。

git commit -m "解决合并冲突" 

避免合并冲突

在团队协作里，频繁出现合并冲突多少会影响开发效率，以及团队士气。

所以我们在工作时会尽量避免冲突的发生。

它的策略核心是尽可能减少同时对同一个文件的修改，以及尽可能减少单次提交的代码量。

• 频繁拉取和推送代码：团队成员应养成频繁拉取（git pull）和推送（git push）代码的习惯，以确保本地仓库与远程仓库保持同步。

• 小步提交：尽量将更改分成小的、独立的提交，而不是一次性提交大量更改。这样可以更容易地解决冲突，并且每次合并的范围更小，冲突的可能性也会降低。

• 使用分支策略：采用合理的分支策略，如 Git Flow 或 GitHub Flow。每个功能或修复都在独立的分支上进行开发，完成后再合并到主分支。这可以减少直接在主分支上进行开发导致的冲突。

• 代码评审：在合并代码之前进行代码评审（Code Review），可以提前发现潜在的冲突和问题，并在合并之前解决。

• 沟通和协调：团队成员之间应保持良好的沟通，特别是在处理同一文件或模块时。提前告知其他成员自己的更改计划，可以避免同时修改同一部分代码。

• 自动化测试：在合并之前运行自动化测试，确保代码的正确性和兼容性。这样可以在合并之前发现并解决潜在的问题。

总结

• 🍑 有三种类型的合并：前进合并（fast-ford）、三方合并（three-way merge）和变基合并（Rebase）。

• 🍑 在进行合并时，还能使用不同的合并策略来控制合并的行为。

• 🍑 在团队协作里，尽量避免冲突的发生。