大家好，我是陈哥，今天想和大家聊聊 Git 合并冲突解决~
前几天，我正好收到了一位读者的留言：又又又又遇到了 Git 合并冲突，解决冲突比写代码还费劲，突然想起 SVN 的好。该怎么避免 Git 冲突啊？
我想，比如这样？
在我看来，Git 合并冲突是不可避免的。在本文，我想和大家简单分享一下遇到 Git 冲突该如何解决，希望对大家有所帮助。 在此之前，我们先来了解一下 Git 的合并冲突是什么以及合并冲突的类型有哪些。或者如果只对如何解决 Git 合并冲突感兴趣，也可以滑至第三部分直接阅读。
在 Git 中，我们在两个不同的分支对同一个文件进行更改，特别是在同一文件的同一行尽心更改，会容易产生合并冲突。 在这种情况下，Git 无法自动解决这些更改之间的不一致性，它会暂停合并过程，并将冲突标记出来，等待我们手动解决。
举一个简单的合并冲突的示例：
当我们准备尝试将 new-feature 分支合并到 main 分支时，Git 无法自动决定在 Hi world 和 Hello earth 之间接受哪一个。因此，Git 会提醒合并冲突错误，并告诉我们手动解决冲突。
这时，Git 会自动用小于号（＜）、等号（=）和大于号（＞）注释出冲突行，如下所示：
<<<<<<< HEAD(Current Change)
Hi world
=======
Hello earth
>>>>>>> new-feature(Incoming Change)
小于号（<）和等号（＝）之间的内容是当前分支（Current Change）中的更改。等号（＝）和大于号（＞）之间的内容是我们要合并到另一个分支的分支变更。
我们可以自行删除这些注释，再决定如何处理冲突代码行。因此，我们不必将合并冲突看作绊脚石，而可以将其作为需要删除的一些注释以及需要接受或拒绝的内容。
常见的合并冲突有两种类型：内容冲突和结果冲突。
我们在两个不同分支上，对同一行代码进行修改，就会发生内容冲突。例如，我们在一个分支的第 2 行修改了 display: flex，又在另一个分支的同一文件的第 2 行修改了 text-align: center。这就是会产生内容冲突，Git 会提示我们对代码进行调整。
结构冲突是指我们在两个不同分支上进行的修改会影响同一个文件。虽然彼此之间不发生逐行冲突，但这些更改会影响文件的结构或组织，如重命名变量、函数、移动代码块等。如果发生结构冲突，Git 会提示我们想保留哪些更改。
既然我们已经了解了 Git 的合并冲突以及合并冲突的类型，那么我们具体来看看到底该如何解决 Git 中的合并冲突。
现在许多代码编辑器都能有在本地合并时，解决合并冲突的接口，我将以 vscode 为例子说明如何解决合并冲突。
当我们切换到要合并的分支并运行 git merge branch-to-merge 时，如果存在冲突，系统会提示我们需要解决。vscode 中的界面如下所示：
如果我们还没有准备好解决冲突，可以先通过运行 git merge --abort 来中止合并。如果想要继续解决冲突，我们有三种方式来解决冲突：接受新的更改、接受当前更改或同时接受两个更改。 选择三种方式中的任何一种，就能够解决合并冲突。
运行 git merge 后，点击 “打开合并编辑器”，会出现如下的三个视图：
左侧是新分支的更改，右侧是当前分支的更改，以及两者下方的预览。Incoming 是我们想要合并到目标分支的分支中的更改，而 current 是我们想要合并到的分支中已有的更改。
在合并编辑器中，可使用以下任一方式开始解决冲突：
当然，如果团队在为大型代码库创建了 PR，并出现合并冲突，那么还有另一种解决方法。我们可以通过运行 git pull --rebase upstream main 与 main 重新绑定。这时，我们会看到一个解决冲突的界面以及包含冲突的文件。完成后，运行 git add .、git rebase --continue，然后强制推送到分支。
其实，合并冲突并非全然是坏事，这也是一次代码审查的机会。当我们掌握 Git 合并冲突的处理方法后，会发现团队协作会变得更加顺畅。如果你们还对 Git 有任何疑问，欢迎参加禅道·中国行（西安站），我们将采用游戏工作坊的形式带大家学习、了解 Git。
最后，希望我的分享可以帮助到你，也欢迎给我留言与我讨论。
