如何解决 Git 中的合并冲突

How to resolve merge conflicts in Git

提问by Spoike

How do I resolve merge conflicts in Git?

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

采纳答案by Peter Burns

Try: git mergetool

尝试： git mergetool

It opens a GUI that steps you through each conflict, and you get to choose how to merge. Sometimes it requires a bit of hand editing afterwards, but usually it's enough by itself. It is much better than doing the whole thing by hand certainly.

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

As per @JoshGlover comment:

根据@JoshGlover 评论：

The command

命令

doesn't necessarily open a GUI unless you install one. Running git mergetoolfor me resulted in vimdiffbeing used. You can install one of the following tools to use it instead: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.

除非您安装 GUI，否则不一定会打开 GUI。git mergetool为我奔跑导致vimdiff被利用。您可以安装以下工具之一来使用它：meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.

Below is the sample procedure to use vimdifffor resolve merge conflicts. Based on this link

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

Step 1: Run following commands in your terminal

第 1 步：在终端中运行以下命令

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

This will set vimdiff as the default merge tool.

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

Step 2: Run following command in terminal

第 2 步：在终端中运行以下命令

git mergetool

Step 3: You will see a vimdiff display in following format

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

  ╔═══════╦══════╦════════╗
  ║       ║      ║        ║
  ║ LOCAL ║ BASE ║ REMOTE ║
  ║       ║      ║        ║
  ╠═══════╩══════╩════════╣
  ║                       ║
  ║        MERGED         ║
  ║                       ║
  ╚═══════════════════════╝

These 4 views are

这 4 个视图是

LOCAL – this is file from the current branch

BASE – common ancestor, how file looked before both changes

REMOTE – file you are merging into your branch

MERGED – merge result, this is what gets saved in the repo

LOCAL – 这是来自当前分支的文件

BASE – 共同祖先，文件在两次更改之前的外观

远程 - 您要合并到分支中的文件

MERGED – 合并结果，这是保存在 repo 中的内容

You can navigate among these views using ctrl+w. You can directly reach MERGED view using ctrl+wfollowed by j.

您可以使用ctrl+在这些视图之间导航w。您可以使用ctrl+w后跟j.

More info about vimdiff navigation hereand here

此处和此处有关 vimdiff 导航的更多信息

Step 4. You could edit the MERGED view the following way

第 4 步。您可以通过以下方式编辑 MERGED 视图

If you want to get changes from REMOTE

如果您想从 REMOTE 获取更改

:diffg RE  

If you want to get changes from BASE

如果您想从 BASE 获取更改

:diffg BA  

If you want to get changes from LOCAL

如果您想从 LOCAL 获取更改

:diffg LO 

Step 5. Save, Exit, Commit and Clean up

第 5 步。保存、退出、提交和清理

:wqasave and exit from vi

:wqa保存并退出 vi

git commit -m "message"

git commit -m "message"

git cleanRemove extra files (e.g. *.orig) created by diff tool.

git clean删除由 diff 工具创建的额外文件（例如 *.orig）。

回答by CoolAJ86

Here's a probable use-case, from the top:

这是一个可能的用例，从顶部开始：

You're going to pull some changes, but oops, you're not up to date:

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

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.

So you get up-to-date and try again, but have a conflict:

所以你更新并重试，但有冲突：

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.

So you decide to take a look at the changes:

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

git mergetool

Oh my, oh my, upstream changed some things, but just to use my changes...no...their changes...

Oh my, Oh my, 上游改变了一些东西，但只是为了使用我的改变......不......他们的变化......

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

And then we try a final time

然后我们尝试最后一次

git pull origin master

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

Ta-da!

达达！

回答by Mark E. Haase

I find merge tools rarely help me understand the conflict or the resolution. I'm usually more successful looking at the conflict markers in a text editor and using git log as a supplement.

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

Here are a few tips:

这里有一些提示：

Tip One

提示一

The best thing I have found is to use the "diff3" merge conflict style:

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

git config merge.conflictstyle diff3

git config merge.conflictstyle diff3

This produces conflict markers like this:

这会产生这样的冲突标记：

<<<<<<<
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.
>>>>>>>

The middle section is what the common ancestor looked like. This is useful because you can compare it to the top and bottom versions to get a better sense of what was changed on each branch, which gives you a better idea for what the purpose of each change was.

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

If the conflict is only a few lines, this generally makes the conflict very obvious. (Knowing how to fix a conflict is very different; you need to be aware of what other people are working on. If you're confused, it's probably best to just call that person into your room so they can see what you're looking at.)

如果冲突只有几行，这通常会使冲突非常明显。（知道如何解决冲突是非常不同的；你需要知道其他人正在做什么。如果你感到困惑，最好把那个人叫到你的房间里，这样他们就能看到你在看什么在。）

If the conflict is longer, then I will cut and paste each of the three sections into three separate files, such as "mine", "common" and "theirs".

如果冲突较长，那么我会将三个部分中的每一个剪切并粘贴到三个单独的文件中，例如“我的”、“共同的”和“他们的”。

Then I can run the following commands to see the two diff hunks that caused the conflict:

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

diff common mine
diff common theirs

This is not the same as using a merge tool, since a merge tool will include all of the non-conflicting diff hunks too. I find that to be distracting.

这与使用合并工具不同，因为合并工具也将包括所有非冲突的差异块。我觉得这会让人分心。

Tip Two

技巧二

Somebody already mentioned this, but understanding the intention behind each diff hunk is generally very helpful for understanding where a conflict came from and how to handle it.

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

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

This shows all of the commits that touched that file in between the common ancestor and the two heads you are merging. (So it doesn't include commits that already exist in both branches before merging.) This helps you ignore diff hunks that clearly are not a factor in your current conflict.

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

Tip Three

提示三

Verify your changes with automated tools.

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

If you have automated tests, run those. If you have a lint, run that. If it's a buildable project, then build it before you commit, etc. In all cases, you need to do a bit of testing to make sure your changes didn't break anything. (Heck, even a merge without conflicts can break working code.)

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

Tip Four

技巧四

Plan ahead; communicate with co-workers.

未雨绸缪; 与同事沟通。

Planning ahead and being aware of what others are working on can help prevent merge conflicts and/or help resolve them earlier -- while the details are still fresh in mind.

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

For example, if you know that you and another person are both working on different refactoring that will both affect the same set of files, you should talk to each other ahead of time and get a better sense for what types of changes each of you is making. You might save considerable time and effort if you conduct your planned changes serially rather than in parallel.

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

For major refactorings that cut across a large swath of code, you should strongly consider working serially: everybody stops working on that area of the code while one person performs the complete refactoring.

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

If you can't work serially (due to time pressure, maybe), then communicating about expected merge conflicts at least helps you solve the problems sooner while the details are still fresh in mind. For example, if a co-worker is making a disruptive series of commits over the course of a one-week period, you may choose to merge/rebase on that co-workers branch once or twice each day during that week. That way, if you do find merge/rebase conflicts, you can solve them more quickly than if you wait a few weeks to merge everything together in one big lump.

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

Tip Five

技巧五

If you're unsure of a merge, don't force it.

如果您不确定合并，请不要强行合并。

Merging can feel overwhelming, especially when there are a lot of conflicting files and the conflict markers cover hundreds of lines. Often times when estimating software projects we don't include enough time for overhead items like handling a gnarly merge, so it feels like a real drag to spend several hours dissecting each conflict.

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

In the long run, planning ahead and being aware of what others are working on are the best tools for anticipating merge conflicts and prepare yourself to resolve them correctly in less time.

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

回答by davetron5000

1. Identify which files are in conflict (Git should tell you this).

2. Open each file and examine the diffs; Git demarcates them. Hopefully it will be obvious which version of each block to keep. You may need to discuss it with fellow developers who committed the code.

3. Once you've resolved the conflict in a file git add the_file.

4. Once you've resolved allconflicts, do git rebase --continueor whatever command Git said to do when you completed.

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

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

3. 一旦您解决了文件中的冲突git add the_file。

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

回答by Pat Notz

Check out the answers in Stack Overflow question Aborting a merge in Git, especially Charles Bailey's answerwhich shows how to view the different versions of the file with problems, for example,

查看 Stack Overflow 问题Aborting a merge in 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

回答by kenorb

Merge conflicts happens when changes are made to a file at the same time. Here is how to solve it.

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

gitCLI

git命令行界面

Here are simple steps what to do when you get into conflicted state:

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

1. Note the list of conflicted files with: git status(under Unmerged pathssection).

2. Solve the conflicts separately for each file by one of the following approaches:

   • Use GUI to solve the conflicts: git mergetool(the easiest way).

   • To accept remote/other version, use: git checkout --theirs path/file. This will reject any local changes you did for that file.

   • To accept local/our version, use: git checkout --ours path/file

     ^{However you've to be careful, as remote changes that conflicts were done for some reason.}

     Related: What is the precise meaning of "ours" and "theirs" in git?

   • Edit the conflicted files manually and look for the code block between <<<<</>>>>>then choose the version either from above or below =====. See: How conflicts are presented.

   • Path and filename conflicts can be solved by git add/git rm.

3. Finally, review the files ready for commit using: git status.

   If you still have any files under Unmerged paths, and you did solve the conflict manually, then let Git know that you solved it by: git add path/file.

4. If all conflicts were solved successfully, commit the changes by: git commit -aand push to remote as usual.

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

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

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

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

   • 要接受本地/我们的版本，请使用： git checkout --ours path/file

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

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

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

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

3. 最后，使用以下命令查看准备提交的文件：git status.

   如果您在 下仍有任何文件Unmerged paths，并且您确实手动解决了冲突，则通过以下方式让 Git 知道您已解决它：git add path/file。

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

See also: Resolving a merge conflict from the command lineat GitHub

另请参阅：从GitHub的命令行解决合并冲突

For practical tutorial, check: Scenario 5 - Fixing Merge Conflicts by Katacoda.

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

DiffMerge

差异合并

I've successfully used DiffMergewhich can visually compare and merge files on Windows, macOS and Linux/Unix.

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

It graphically can show the changes between 3 files and it allows automatic merging (when safe to do so) and full control over editing the resulting file.

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

^{Image source: DiffMerge(Linux screenshot)}

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

Simply download it and run in repo as:

只需下载它并在 repo 中运行：

git mergetool -t diffmerge .

---

---

macOS

苹果系统

On macOS you can install via:

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

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

And probably (if not provided) you need the following extra simple wrapper placed in your PATH (e.g. /usr/bin):

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

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

Then you can use the following keyboard shortcuts:

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

• ?-Alt-Up/Downto jump to previous/next changes.
• ?-Alt-Left/Rightto accept change from left or right

• ?- Alt- Up/Down跳转到上一个/下一个更改。
• ?- Alt- Left/Right接受从左到右的改变

Alternatively you can use opendiff(part of Xcode Tools) which lets you merge two files or directories together to create a third file or directory.

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

回答by Paul

If you're making frequent small commits, then start by looking at the commit comments with git log --merge. Then git diffwill show you the conflicts.

如果您经常进行小型提交，请先查看带有git log --merge. 然后git diff将向您展示冲突。

For conflicts that involve more than a few lines, it's easier to see what's going on in an external GUI tool. I like opendiff -- Git also supports vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, emerge out of the box and you can install others: git config merge.tool "your.tool"will set your chosen tool and then git mergetoolafter a failed merge will show you the diffs in context.

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

Each time you edit a file to resolve a conflict, git add filenamewill update the index and your diff will no longer show it. When all the conflicts are handled and their files have been git add-ed, git commitwill complete your merge.

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

回答by Paul

See How Conflicts Are Presentedor, in Git, the git mergedocumentation to understand what merge conflict markers are.

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

Also, the How to Resolve Conflictssection explains how to resolve the conflicts:

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

After seeing a conflict, you can do two things:

• Decide not to merge. The only clean-ups you need are to reset the index file to the HEADcommit to reverse 2. and to clean up working tree changes made by 2. and 3.; git merge --abortcan be used for this.

• Resolve the conflicts. Git will mark the conflicts in the working tree. Edit the files into shape and git addthem to the index. Use git committo seal the deal.

You can work through the conflict with a number of tools:

• Use a mergetool. git mergetoolto launch a graphical mergetool which will work you through the merge.

• Look at the diffs. git diffwill show a three-way diff, highlighting changes from both the HEADand MERGE_HEADversions.

• Look at the diffs from each branch. git log --merge -p <path>will show diffs first for the HEADversion and then the MERGE_HEADversion.

• Look at the originals. git show :1:filenameshows the common ancestor, git show :2:filenameshows the HEADversion, and git show :3:filenameshows the MERGE_HEADversion.

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

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

• 解决冲突。Git 会在工作树中标记冲突。将文件编辑成形状并将git add它们添加到索引中。用于git commit达成交易。

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

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

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

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

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

You can also read about merge conflict markers and how to resolve them in the Pro Gitbook section Basic Merge Conflicts.

您还可以在Pro Git书籍部分Basic Merge Conflicts 中了解合并冲突标记以及如何解决它们。

回答by Noidea

I either want my or their version in full, or want to review individual changes and decide for each of them.

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

Fully accept my or theirs version:

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

Accept my version (local, ours):

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

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

Accept their version (remote, theirs):

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

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

If you want to do for all conflict filesrun:

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

git merge --strategy-option ours

or

或者

git merge --strategy-option theirs

Review all changes and accept them individually

查看所有更改并单独接受

1. git mergetool
2. Review changes and accept either version for each of them.
3. git add <filename>
4. git commit -m "merged bla bla"

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

Default mergetoolworks in command line. How to use a command line mergetool should be a separate question.

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

You can also install visual toolfor this, e.g. meldand run

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

git mergetool -t meld

It will open local version (ours), "base" or "merged" version (the current result of the merge) and remote version (theirs). Save the merged version when you are finished, run git mergetool -t meldagain until you get "No files need merging", then go to Steps 3. and 4.

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

回答by eci

For Emacsusers which want to resolve merge conflicts semi-manually:

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

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

shows all files which require conflict resolution.

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

Open each of those files one by one, or all at once by:

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

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

When visiting a buffer requiring edits in Emacs, type

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

ALT+x vc-resolve-conflicts

This will open three buffers (mine, theirs, and the output buffer). Navigate by pressing 'n' (next region), 'p' (prevision region). Press 'a' and 'b' to copy mine or theirs region to the output buffer, respectively. And/or edit the output buffer directly.

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

When finished: Press 'q'. Emacs asks you if you want to save this buffer: yes. After finishing a buffer mark it as resolved by running from the teriminal:

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

git add FILENAME

When finished with all buffers type

完成所有缓冲区类型后

git commit

to finish the merge.

完成合并。