如何解决 Git 存储库中的合并冲突？

Question

如何解决 Git 存储库中的合并冲突？

Answer 1

尝试：

git mergetool

它会打开一个 GUI，引导您解决每个冲突，然后您可以选择如何合并。 有时事后需要进行一些手动编辑，但通常本身就足够了。 这肯定比手工完成整个事情要好得多。

---

根据 Josh Glover 的评论：

[此命令]
除非您安装了 GUI，否则不一定会打开 GUI。 为我运行 git mergetool 导致使用 vimdiff 。 您可以安装
使用以下工具之一来代替：meld、opendiff、
kdiff3、tkdiff、xxdiff、tortoisemerge、gvimdiff、diffuse< /代码>,
ecmerge、p4merge、araxis、vimdiff、emerge。




---

下面是使用 vimdiff 解决合并冲突的示例过程，基于 此链接。

1. 在终端中运行以下命令

   git config merge.tool vimdiff 
     git config merge.conflictstyle diff3 
     git config mergetool.prompt false 
     

   这会将 vimdiff 设置为默认合并工具。

2. 在终端中运行以下命令

   git mergetool 
     

3. 您将看到以下格式的 vimdiff 显示：

   <代码> ╔═══════╦══════╦════════╗ 
       ║║║║ 
       ║ 本地 ║ 基地 ║ 远程 ║ 
       ║║║║ 
       ╠═══════╩══════╩════════╣ 
       ║║ 
       ║ 合并║ 
       ║║ 
       ╚═══════════════════════╝ 
     

   这 4 个视图是

   • 本地：这是当前分支中的文件
   • BASE：共同的祖先，该文件在两次更改之前的外观
   • 远程：您要合并到分支中的文件
   • MERGED：合并结果； 这是在合并提交中保存并在将来使用的内容

   您可以使用 ctrl+w 在这些视图之间导航。 您可以使用 ctrl+w 后跟 j 直接访问 MERGED 视图。

   有关 vimdiff 导航的更多信息位于此处以及此处。。 p>

4. 您可以像这样编辑 MERGED 视图：

   • 如果您想从 REMOTE 获取更改

     <前><代码>:diffg RE

   • 如果您想从 BASE 获取更改

     <前><代码>：diffg BA

   • 如果您想从 LOCAL 获取更改

     <前><代码>:diffg LO

5. 保存、退出、提交和清理

   :wqa保存并退出vi

   git commit -m“消息”

   git clean 删除多余的文件（例如*.orig）。 警告：如果您不传递任何参数，它将删除所有未跟踪的文件。

Answer 2

从上到下，这是一个可能的用例：

您将进行一些更改，但是哎呀，您不是最新的：

git fetch origin
git pull origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Updating a030c3a..ee25213
error: Entry 'filename.c' not uptodate. Cannot merge.

所以您获得最新的并重试，但有冲突：

git add filename.c
git commit -m "made some wild and crazy changes"
git pull origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Auto-merging filename.c
CONFLICT (content): Merge conflict in filename.c
Automatic merge failed; fix conflicts and then commit the result.

所以您决定看看这些变化：

git mergetool

哦天哪，哦天哪，上游改变了一些东西，但只是为了使用我的改变......不......他们的改变......

git checkout --ours filename.c
git checkout --theirs filename.c
git add filename.c
git commit -m "using theirs"

然后我们最后一次尝试

git pull origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Already up-to-date.

Ta-da！

Answer 3

我发现合并工具很少能帮助我理解冲突或解决方案。 我通常更成功地查看文本编辑器中的冲突标记并使用 git log 作为补充。

这里有一些提示：

提示一

我发现的最好的办法是使用“diff3”合并冲突样式：

git config merge.conflictstyle diff3

这会产生如下所示的冲突标记：

<<<<<<<
Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
|||||||
The common ancestor version.
=======
Changes made on the branch that is being merged in. This is often a 
feature/topic branch.
>>>>>>>

中间部分是什么共同的祖先看起来像。 这很有用，因为您可以将其与顶部和底部版本进行比较，以更好地了解每个分支上的更改内容，从而更好地了解每个更改的目的是什么。

如果冲突只有几行，通常会使冲突变得非常明显。 （知道如何解决冲突是非常不同的；您需要了解其他人正在做什么。如果您感到困惑，最好将那个人叫到您的房间，以便他们可以看到您正在寻找的内容 如果冲突较长

，那么我会将这三个部分分别剪切并粘贴到三个单独的文件中，例如“我的”、“共同的”和“他们的”。

然后我可以运行以下命令来查看导致冲突的两个 diff 块：

diff common mine
diff common theirs

这与使用合并工具不同，因为合并工具也将包含所有不冲突的 diff 块。 我发现这让人分心。

提示

二 有人已经提到过这一点，但是理解每个差异块背后的意图通常对于理解冲突从何而来以及如何处理它非常有帮助。

git log --merge -p <name of file>

这显示了在共同祖先和您要合并的两个头之间触及该文件的所有提交。 （因此它不包括合并之前两个分支中已经存在的提交。）这可以帮助您忽略明显不是当前冲突因素的差异块。

提示三

使用自动化工具验证您的更改。

如果您有自动化测试，请运行它们。 如果您有 lint，请运行它。 如果它是一个可构建的项目，那么在提交之前构建它，等等。在所有情况下，您都需要进行一些测试以确保您的更改不会破坏任何内容。 （哎呀，即使没有冲突的合并也可能会破坏工作代码。）

技巧四

提前计划； 与同事沟通。

提前计划并了解其他人正在做什么可以帮助防止合并冲突和/或帮助尽早解决它们——同时细节仍然记忆犹新。

例如，如果您知道您和另一个人都在进行不同的重构，而这些重构都会影响同一组文件，那么您应该提前相互交谈，并更好地了解你们每个人正在做什么类型的更改制作。 如果您连续而不是并行地进行计划的更改，您可能会节省大量时间和精力。

对于跨越大量代码的主要重构，您应该强烈考虑串行工作：每个人都停止处理该代码区域，而一个人执行完整的重构。

如果您无法连续工作（可能是由于时间压力），那么就预期的合并冲突进行沟通至少可以帮助您更快地解决问题，同时细节仍然记忆犹新。 例如，如果一位同事在一周内进行一系列破坏性提交，您可以选择在该周内每天对该同事分支进行一次或两次合并/变基。 这样，如果您确实发现合并/变基冲突，您可以比等待几周将所有内容合并在一起更快地解决它们。

提示五

如果您不确定是否要合并，请不要强迫它。

合并可能会让人感到不知所措，尤其是当存在大量冲突文件并且冲突标记覆盖数百行时。 很多时候，在评估软件项目时，我们没有足够的时间来处理诸如处理粗糙合并之类的开销项目，因此花费几个小时来剖析每个冲突感觉确实很麻烦。

从长远来看，提前计划并了解其他人正在做什么是预测合并冲突并准备在更短的时间内正确解决它们的最佳工具。

Answer 4

1. 确定哪些文件存在冲突（Git 应该告诉您这一点）。

2. 打开每个文件并检查差异； Git 对它们进行了划分。 希望保留每个块的版本是显而易见的。 您可能需要与提交代码的其他开发人员讨论。

3. 解决文件中的冲突后，git add the_file。

4. 解决所有冲突后，执行git rebase --continue或任何命令
   Git 表示在完成后执行。

Answer 5

当同时对文件进行更改时，就会发生合并冲突。 以下是解决方法。

git CLI

以下是进入冲突状态时应执行的简单步骤：

1. 记下冲突文件列表：git status（在 Unmerged paths 部分）。

2. 通过以下方法之一分别解决每个文件的冲突：

   • 使用 GUI 解决冲突：git mergetool（最简单的方法）。

   • 要接受远程/其他版本，请使用：git checkout --theirs path/file。 这将拒绝您对该文件所做的任何本地更改。

   • 要接受本地/我们的版本，请使用：git checkout --ours 路径/文件

     ^{但是您必须小心，因为由于某种原因发生冲突的远程更改。}

     相关：git中“我们的”和“他们的”的确切含义是什么？

     < /里>

   • 手动编辑冲突文件并查找 <<<<<<</>>>>>< 之间的代码块/code> 然后从上方或下方选择版本=====。 请参阅：如何呈现冲突。

   • 路径和文件名冲突可以通过git add/git rm解决。

3. 最后，使用 git status 查看准备提交的文件。

   如果未合并路径下仍有任何文件，并且您确实手动解决了冲突，请让 Git 知道您已通过以下方式解决了该问题：git add path/file .

4. 如果所有冲突均已成功解决，请通过以下方式提交更改：git commit -a 并照常推送到远程。

另请参阅：通过命令解决合并冲突行位于 GitHub

有关实用教程，请检查：场景 5 - Katacoda 修复合并冲突。

DiffMerge

我已经成功使用了 DiffMerge，它可以在 Windows、macOS 和 Linux/Unix 上直观地比较和合并文件。

它可以以图形方式显示 3 个文件之间的更改，并允许自动合并（在安全的情况下）并完全控制编辑结果文件。

^{图片来源：DiffMerge（Linux 屏幕截图）}

只需下载并运行在存储库中为：

git mergetool -t diffmerge .

---

macOS

在 macOS 上，您可以通过以下方式安装：

brew install caskroom/cask/brew-cask
brew cask install diffmerge

并且可能（如果未提供）您需要将以下额外的简单包装器放置在您的 PATH 中（例如 /usr/bin）：

#!/bin/sh
DIFFMERGE_PATH=/Applications/DiffMerge.app
DIFFMERGE_EXE=${DIFFMERGE_PATH}/Contents/MacOS/DiffMerge
exec ${DIFFMERGE_EXE} --nosplash "$@"

然后您可以使用以下键盘快捷键：

• ⌘-Alt-向上/向下跳转到上一个/下一个更改。
• ⌘-Alt-Left/Right 接受左侧或右侧的更改

或者您可以使用 opendiff（Xcode工具的一部分）让您将两个文件或目录合并在一起以创建第三个文件或目录。

Answer 6

查看 Stack Overflow 问题中的答案中止 Git 中的合并，尤其是 Charles Bailey 的回答，它展示了如何查看不同版本的有问题的文件，例如

# Common base version of the file.
git show :1:some_file.cpp

# 'Ours' version of the file.
git show :2:some_file.cpp

# 'Theirs' version of the file.
git show :3:some_file.cpp

Answer 7

如果您经常进行小型提交，请首先使用 git log --merge 来查看提交注释。 然后 git diff 会显示冲突。

对于涉及多于几行的冲突，可以更轻松地查看外部 GUI 工具中发生的情况。 我喜欢 opendiff —— Git 还支持 vimdiff、gvimdiff、kdiff3、tkdiff、meld、xxdiff、emerge 开箱即用，你可以安装其他的：git config merge.tool "your.tool" 将设置您选择的工具以及合并失败后的 git mergetool 会向您显示上下文中的差异。

每次您编辑文件以解决冲突时，git add filename 都会更新索引，并且您的 diff 将不再显示它。 当所有冲突都得到处理并且它们的文件已被 git add 编辑后，git commit 将完成合并。

Answer 8

我要么想要我的或他们的完整版本，要么想要查看各个更改并为每个更改做出决定。

完全接受我或他们的版本：

接受我的版本（本地、我们的）：

git checkout --ours -- <filename>
git add <filename>              # Marks conflict as resolved
git commit -m "merged bla bla"  # An "empty" commit

接受他们的版本（远程、他们的）：

git checkout --theirs -- <filename>
git add <filename>
git commit -m "merged bla bla"

如果您想对所有冲突文件执行以下操作：

git merge --strategy-option ours

或

git merge --strategy-option theirs

查看所有更改并单独接受它们

1. git mergetool
2. 查看更改并接受每个更改的任一版本。
3. git add
4. git commit -m "merged bla bla"

默认 mergetool 在命令行中工作。 如何使用命令行合并工具应该是一个单独的问题。

您还可以为此安装可视化工具，例如meld并运行

git mergetool -t meld

它将打开本地版本（我们的）、“基础”或“合并”版本（当前结果）合并）和远程版本（他们的）。 完成后保存合并的版本，再次运行 git mergetool -t meld 直到出现“没有文件需要合并”，然后转到步骤 3 和 4。

Answer 9

请参阅如何呈现冲突或者，在 Git 中，可以使用 git merge 文档来了解什么是合并冲突标记。

另外，如何解决冲突部分解释了如何解决冲突：

看到冲突后，您可以做两件事：

• 决定不合并。 您需要的唯一清理是将索引文件重置为 HEAD 提交以反转 2. 并清理 2. 和 3. 所做的工作树更改； 可以使用 git merge --abort 来实现此目的。

• 解决冲突。 Git 会在工作树中标记冲突。 将文件编辑为 shape 并将它们 git add 到索引中。 使用 git commit 来达成交易。

您可以使用多种工具解决冲突：

• 使用合并工具。 git mergetool 启动图形合并工具，它将帮助您完成合并。

• 查看差异。 git diff 将显示三向差异，突出显示 HEAD 和 MERGE_HEAD 版本的更改。

• 查看每个分支的差异。 git log --merge -p 将首先显示 HEAD 版本的差异，然后显示 MERGE_HEAD 版本的差异。

• 看原著。 git show :1:filename 显示共同祖先，git show :2:filename 显示 HEAD 版本，git show : 3:filename 显示MERGE_HEAD 版本。

您还可以在 Pro Git 书籍部分 基本合并冲突。

Answer 10

对于想要半手动解决合并冲突的 Emacs 用户：

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

显示所有需要解决冲突的文件。

通过以下方式逐一打开每个文件，或一次全部打开：

emacs $(git diff --name-only --diff-filter=U)

当访问需要在 Emacs 中编辑的缓冲区时，键入

ALT+x vc-resolve-conflicts

这将打开三个缓冲区（我的、他们的和输出缓冲区）。 按“n”（下一个区域）、“p”（预览区域）进行导航。 按“a”和“b”分别将我的或他们的区域复制到输出缓冲区。 和/或直接编辑输出缓冲区。

完成后：按“q”。 Emacs 询问您是否要保存此缓冲区：是。
完成缓冲区后，通过从终端运行将其标记为已解决：

git add FILENAME

完成所有缓冲区后，键入

git commit

以完成合并。

Answer 11

奖励：

在前面的答案中谈到拉/取/合并时，我想分享一个有趣且富有成效的技巧，

git pull --rebase

上面的命令是我的 Git 生活中最有用的命令，节省了大量时间。

在将新提交的更改推送到远程服务器之前，请尝试使用 git pull --rebase 而不是 git pull 和手动 merge，它将自动同步最新版本远程服务器更改（使用 fetch + merge）并将本地最新提交放在 Git 日志的顶部。 无需担心手动拉取/合并。

如果发生冲突，只需使用

git mergetool
git add conflict_file
git rebase --continue

查找详细信息：“git pull –rebase”是什么做什么？

Answer 12

简而言之，如果您很清楚其中一个存储库中的更改并不重要，并且希望解决有利于另一个存储库的所有更改，请使用：

git checkout . --ours

解决有利于您的存储库的更改，或者

git checkout . --theirs

解决有利于其他或主存储库的更改。

否则，您将不得不使用 GUI 合并工具逐个浏览文件，假设合并工具是 p4merge，或者写下您已经安装的任何人的名字

git mergetool -t p4merge

，完成文件后，您必须保存并关闭，以便下一个将打开。

Answer 13

共有三个步骤：

1. 通过命令查找哪些文件引起冲突

    git 状态 
     

2. 检查文件，在其中您会发现冲突标记为

   <前><代码> <<<<<<<

3. 将其更改为您想要的方式，然后使用命令提交

    git addsolved_conflicts_files 
      git commit -m '合并消息' 
     

Answer 14

请按照以下步骤修复 Git 中的合并冲突：

1. 检查 Git 状态：
   git status

2. 获取补丁集：
   git fetch（从 Git 提交中签出正确的补丁）

3. 签出本地分支（在我的示例中为 temp1）：
   git checkout -b temp1

4. 从 master 中提取最近的内容：
   git pull --rebase origin master

5. 启动 mergetool 并检查冲突并修复它们...并检查远程分支与当前分支的更改：
   git mergetool

6. 再次检查状态：
   git status

7. 删除mergetool本地创建的不需要的文件，通常mergetool会创建带有*.orig扩展名的额外文件。 请删除该文件，因为这只是重复的文件，并在本地修复更改并添加文件的正确版本。
   git add #your_changed_ Correct_files

8. 再次检查状态：
   git status

9. 将更改提交到同一提交 ID（这避免了新的单独补丁集）：
   git commit --amend

10. 推送到主分支：
    git push（到您的 Git 存储库）

Answer 15

CoolAJ86 的回答几乎概括了一切。 如果您在同一段代码的两个分支中进行了更改，则必须进行手动合并。 在任何文本编辑器中打开冲突文件，您应该看到以下结构。

(Code not in Conflict)
>>>>>>>>>>>
(first alternative for conflict starts here)
Multiple code lines here
===========
(second alternative for conflict starts here)
Multiple code lines here too    
<<<<<<<<<<<
(Code not in conflict here)

按照您希望新代码的方式选择其中一种替代方案或两者的组合，同时删除等号和尖括号。

git commit -a -m "commit message"
git push origin master

Answer 16

您可以通过多种方式解决合并冲突，正如其他人详细介绍的那样。

我认为真正的关键是了解更改如何在本地和远程存储库中流动。 关键是理解跟踪分支。 我发现我认为跟踪分支是我的本地实际文件目录和定义为源的远程目录之间的“中间缺失的一块”。

我个人养成了两件事的习惯来帮助避免这种情况。

而不是：

git add .
git commit -m"some msg"

它有两个缺点 -

a) 所有新的/更改的文件都会被添加，并且可能包括一些不需要的更改。
b) 您不必先查看文件列表。

所以我这样做：

git add file,file2,file3...
git commit # Then type the files in the editor and save-quit.

这样您就可以更加仔细地考虑添加哪些文件，并且您还可以在使用消息编辑器时查看列表并进行更多思考。 我发现当我使用全屏编辑器而不是 -m 选项时，它还改进了我的提交消息。

[更新 - 随着时间的推移，我已经切换到更多：

git status # Make sure I know whats going on
git add .
git commit # Then use the editor

]

另外（并且与您的情况更相关），我尝试避免：

git pull

或者

git pull origin master.

因为拉意味着合并，如果您在本地进行了更改，则您不想合并您很容易导致合并代码和/或不应该合并的代码的合并冲突。

相反，我尝试这样做，

git checkout master
git fetch   
git rebase --hard origin/master # or whatever branch I want.

您可能还会发现这很有帮助：

git分支、fork、fetch、merge、rebase和clone，有什么区别？

Answer 17

如果您想从分支test合并到master，可以按照以下步骤操作：

第1步：转到分支

git checkout test

第2步：

git pull --rebase origin master

第3步：如果有冲突，请到这些文件中进行修改。

步骤 4：添加这些更改

git add #your_changes_files

步骤 5：

git rebase --continue

步骤 6：如果仍然存在冲突，请再次返回步骤 3。 如果没有冲突，则执行以下操作：

git push origin +test

第7步：这样test和master之间就没有冲突了。 可以直接使用合并。

Answer 18

使用 patience

对于大的合并冲突，使用 patience 为我提供了良好的结果。 它将尝试匹配块而不是单独的行。

例如，如果您更改程序的缩进，默认的 Git 合并策略有时会匹配属于不同函数的单大括号 { 。 通过耐心可以避免这种情况：

git merge -s recursive -X patience other-branch

来自文档：

With this option, merge-recursive spends a little extra time to avoid 
mismerges that sometimes occur due to unimportant matching lines 
(e.g., braces from distinct functions). Use this when the branches to 
be merged have diverged wildly.

与共同祖先的比较

如果您遇到合并冲突并且想了解其他人在修改其分支时的想法，有时直接比较他们的分支会更容易与共同的祖先（而不是我们的分支）。 为此，您可以使用 merge-base：

git diff $(git merge-base <our-branch> <their-branch>) <their-branch>

通常，您只想查看特定文件的更改：

git diff $(git merge-base <our-branch> <their-branch>) <their-branch> <file>

Answer 19

git log --merge -p [[--] path]

似乎并不总是对我有用，通常最终会显示两个分支之间不同的每个提交，即使使用 -- 将路径与命令分开时也会发生这种情况。

我解决这个问题的方法是打开两个命令行，在一次运行中

git log ..$MERGED_IN_BRANCH --pretty=full -p [path]

，在另一次

git log $MERGED_IN_BRANCH.. --pretty=full -p [path]

运行中将 $MERGED_IN_BRANCH 替换为我合并的分支，将 [path] 替换为存在冲突的文件。 此命令将以补丁形式记录 (..) 两次提交之间的所有提交。 如果您像上面的命令一样将一侧留空，git 将自动使用 HEAD （在本例中您要合并到的分支）。

这将允许您查看两个分支分叉后哪些提交进入了文件。 它通常使解决冲突变得更加容易。

Answer 20

自 2016 年 12 月 12 日起，您可以合并分支并解决 github.com 上的冲突。

因此，如果您不想使用此处提供的命令行或任何第三方工具从旧的答案，使用 GitHub 的本机工具。

这篇博文详细解释了，但基础知识是通过用户界面“合并”两个分支后，您现在将看到一个“解决冲突”选项，该选项将带您进入编辑器，允许您处理这些合并冲突。

Answer 21

合并冲突可能在不同情况下发生：

• 当运行 git fetch 然后运行 ​​git merge
• 当运行 git fetch 然后运行 ​​git rebase
• 当运行 git pull 时（实际上等于上述条件之一）
• 当运行 git stash pop
• 当你应用 git 补丁时（提交是导出到要传输的文件，例如通过电子邮件）

您需要安装与Git兼容的合并工具来解决冲突。 我个人使用 KDiff3，我发现它很好而且很方便。 您可以在此处下载其 Windows 版本：

https://sourceforge.net/projects/kdiff3/files/< /a>

顺便说一句，如果您安装了 Git Extensions，其安装向导中会有一个选项来安装 Kdiff3。

然后设置 Git 配置以使用 KDiff3 作为其合并工具：（

$ git config --global --add merge.tool kdiff3
$ git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add mergetool.kdiff3.trustExitCode false

$ git config --global --add diff.guitool kdiff3
$ git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add difftool.kdiff3.trustExitCode false

记住将路径替换为 KDiff3 EXE 文件的实际路径。）

然后每次遇到合并冲突时，只需运行此命令：

$ git mergetool

然后它会打开Kdiff3，首先尝试自动解决合并冲突。 大多数冲突会自发解决，其余冲突需要您手动解决。

Kdiff3 如下所示：

完成后，保存文件，它将转到下一个有冲突的文件，然后再次执行相同的操作，直到解决所有冲突。

要检查所有内容是否合并成功，只需再次运行 mergetool 命令即可。 你应该得到这个结果：

$ git mergetool
No files need merging

Answer 22

我始终遵循以下步骤以避免冲突。

• git checkout master （来到master分支）
• git pull （更新你的master以获取最新代码）
• git checkout -b mybranch （检查建立一个新的分支并开始在该分支上工作，以便您的 master 始终保持在主干的顶部。）
• git add . 和 git commit < em>和 git Push（更改后在本地分支上）
• git checkout master（回到你的 master 那里）

现在你可以做同样的事情并维护只要有必要，只需对您的分支执行 git checkout 即可同时工作任意数量的本地分支。

Answer 23

我明白什么是合并冲突，但是当我看到 git diff 的输出时，一开始对我来说这看起来像是无稽之谈：

git diff
++<<<<<<< HEAD
 + display full last name boolean in star table
++=======
+ users viewer.id/star.id, and conversation uses user.id
+
++>>>>>>> feat/rspec-tests-for-cancancan

但是 这里对我有帮助：

• <<<<<<<<<<之间的所有内容; 和 ======= 是一个文件中的内容，并且

• ======= 和 >>>>>>> 之间的所有内容都是在另一个文件中

• 因此，实际上您所要做的就是打开存在合并冲突的文件，并从任一分支中删除这些行（或者只是使它们相同），并且合并将立即成功。 问题解决了！

Answer 24

适用于 Visual Studio Code 的 GitLens

您可以尝试适用于 Visual Studio Code 的 GitLens。 主要功能是：

1. 轻松解决冲突

我已经喜欢这个功能了：

2. 当前行责怪。

3. 装订线责备

4. 状态栏责怪

还有很多功能。 您可以在此处查看它们。

Answer 25

这个答案是为像我这样喜欢在编辑器中完成所有操作的 Vim 用户添加一个替代方案。

---

TL;DR

---

Tpope 为 Vim 想出了这个很棒的插件，名为 逃犯。 安装后，您可以运行 :Gstatus 来检查有冲突的文件，并运行 :Gdiff 以三向合并方式打开 Git。

一旦进入三向合并，fugitive将让您以以下方式获取正在合并的任何分支的更改：

• :diffget //2，获取更改从原始 (HEAD) 分支：
• :diffget //3，从合并分支获取更改：

完成合并文件后，输入 :Gwrite 在合并缓冲区中。

Vimcasts 发布了一个很棒的视频，解释了这些步骤细节。

Answer 26

我正在使用 Microsoft 的 Visual Studio Code 来解决冲突。 使用起来非常简单。 我让我的项目在工作区中保持打开状态。 它检测并突出显示冲突。 此外，它提供了 GUI 选项来选择我想要从 HEAD 或传入中保留的任何更改。

Answer 27

git fetch <br>
git checkout **your branch**<br>
git rebase master<br>

在此步骤中，您将尝试使用您首选的 IDE 修复冲突。

您可以点击此链接检查如何修复文件中的冲突。

git add<br>
git rebase --continue<br>
git commit --amend<br>
git push origin HEAD:refs/drafts/master  (push like a drafts)<br>

现在一切都很好，您将在 Gerrit 中找到您的提交。

Answer 28

如果您使用 IntelliJ IDEA 作为 IDE，请尝试通过以下方式将父级合并到您的分支：

git checkout <localbranch>
git merge origin/<remotebranch>

它将显示所有冲突，如下所示：

A_MBPro:测试 anu$ git merge origin/自动合并
src/test/java/com/.../TestClass.java 冲突
（内容）：合并冲突
src/test/java/com/.../TestClass.java

现在请注意，文件 TestClass.java 在 IntelliJ IDEA 中显示为红色。

此外，git status 将显示：

Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified:   src/test/java/com/.../TestClass.java

在 IntelliJ IDEA 中打开文件。 它将包含一些部分，

  <<<<<<< HEAD
    public void testMethod() {
    }
    =======
    public void testMethod() { ...
    }
    >>>>>>> origin/<remotebranch>

其中 HEAD 在本地分支和 origin/ 上发生更改。 是来自远程分支的更改。 这里保留你需要的东西，删除你不需要的东西。 之后，应该执行正常步骤。 那是

   git add TestClass.java
   git commit -m "commit message"
   git push

Answer 29

如果您还没有尝试过使用 Visual Studio Code 进行编辑。

尝试合并（并陷入合并冲突）后，Visual Studio Code 会自动检测合并冲突。

它可以通过显示对原始更改所做的更改以及您是否应该接受传入或

当前更改（指合并之前的原始更改）来为您提供帮助。

它对我有帮助，也对你有用！

PS：仅当您使用代码和 Visual Studio Code 配置了 Git 时，它才有效。

Answer 30

解决冲突的更安全方法是使用 git-mediate （这里建议的常见解决方案相当恕我直言，容易出错）。

请参阅这篇文章 快速介绍如何使用它。