如何在 Git 中手动合并所有文件？

How to merge all files manually in Git?

提问by gennad

I want to merge all files manuallywith meld or any other diff tool, how can I do this with Git?
When I run git mergetoolit says no files need merging. So I suppose I can do it only if I have conflicts.

我想使用 meld 或任何其他差异工具手动合并所有文件，我该如何使用 Git 做到这一点？
当我运行git mergetool它说no files need merging。所以我想只有当我有冲突时我才能做到。

回答by skywinder

There is much simpler way:

有更简单的方法：

git merge --no-commit merge_branch

git merge --no-commit merge_branch

As man says:

正如男人所说：

With --no-commitperform the merge but pretend the merge failed and do not autocommit, to give the user a chance to inspect and further tweak the merge result before committing.

随着--no-commit执行合并，但假装失败的合并，不自动提交，给用户提供一个机会来检查和进一步提交之前调整合并结果。

回答by NSjonas

I had a scenario where:

我有一个场景：

git merge --no-commit merge_branch 

just caused a Fast Forward.

只是引起了快进。

If this happens you can use:

如果发生这种情况，您可以使用：

git merge --no-commit --no-ff merge_branch

and then you'll be able to review your changes

然后您就可以查看您的更改

回答by True

A similar question is How to prevent an automerge using git?

一个类似的问题是如何使用 git 防止自动合并？

FractalSpace gave an answer which I think useful:

FractalSpace 给出了一个我认为有用的答案：

$ git checkout master
$ git difftool -t kdiff3 local-branch HEAD

The idea is using difftools instead of auto-merging tools to manually pick what you need and create new files.

这个想法是使用 difftools 而不是自动合并工具来手动选择您需要的内容并创建新文件。

回答by VonC

Note, if you insists of merging manually (perhaps for a certain class of files), you still can define a merge driver.
You have a concrete example in "Git - how to force merge conflict and manual merge on selected file".

请注意，如果您坚持手动合并（可能针对某类文件），您仍然可以定义合并驱动程序。
您在“ Git - 如何在选定文件上强制合并冲突和手动合并”中有一个具体示例。

That way, your merge driver script can call any merge tool you want.

这样，您的合并驱动程序脚本可以调用您想要的任何合并工具。

回答by stevegt

For anyone who came here and is now wondering about the difference between @True's answer using git difftooland the other answers that use git merge, see Git mergetool vs difftool.

对于来到这里并且现在想知道@True的答案 usinggit difftool和其他使用的答案之间的区别的人git merge，请参阅Git mergetool vs difftool。

In short, if you have git configured to use a modern diff.toolsuch as kdiff3, meld, or vimdiff, you'll be able to manually merge using that diff tool, and the command line can be simple:

简而言之，如果您将 git 配置为使用diff.tool诸如 kdiff3、meld 或 vimdiff 之类的现代工具，您将能够使用该 diff 工具手动合并，并且命令行可以很简单：

git difftool other_branch

...this will let you do a two-way manual merge between your current branch and other_branch (described as $LOCAL and $REMOTE in man git-config).

...这将让您在当前分支和 other_branch（在 中描述为 $LOCAL 和 $REMOTE man git-config）之间进行双向手动合并。

The "correct" way the other answers discuss would be to instead configure git to use e.g. kdiff3 or vimdiff as your merge.tool, and use:

其他答案讨论的“正确”方式是将 git 配置为使用例如 kdiff3 或 vimdiff 作为您的merge.tool，并使用：

git merge --no-commit --no-ff other_branch
git mergetool

...this command can do an N-way manual merge between $BASE, $LOCAL, and $REMOTE, into $MERGED. See https://stackoverflow.com/a/2235841/1264797for one example of how to configure git. You many not need to configure the mergetool.*.cmdentry at all if you use one of the tools git already knows about. (Meld can only show three panes, so if you use meld with the default settings, you'll not see $BASE.)

...此命令可以在 $BASE、$LOCAL 和 $REMOTE 之间进行 N 路手动合并，并生成 $MERGED。有关如何配置 git 的一个示例，请参阅 https://stackoverflow.com/a/2235841/1264797。mergetool.*.cmd如果您使用 git 已经知道的工具之一，那么您根本不需要配置条目。（Meld 只能显示三个窗格，因此如果您使用带有默认设置的 meld，您将看不到 $BASE。）

Someone might jump in to correct me, but other than the N-way merge ability, the two methods appear to produce the same result. Neither difftoolnor mergetooladds other_branch as a parent on the new commit, so in both cases, the merge isn't obvious in e.g. gitk and would have to be described (and noticed later) in the commit message.

有人可能会跳出来纠正我，但除了 N 路合并能力之外，这两种方法似乎产生了相同的结果。既没有difftool也没有mergetool添加 other_branch 作为新提交的父级，因此在这两种情况下，合并在例如 gitk 中并不明显，并且必须在提交消息中进行描述（并在稍后注意到）。

回答by Tomasz Janicki

I pick strategy ours(it exist also as a pick in TortoiseGit), after doing a manual diff where you have brought-in changes you wanted manually.

我选择了我们的策略（它也作为 TortoiseGit 中的一个选择存在），在做了一个手动差异之后，你手动引入了你想要的更改。

From: https://git-scm.com/docs/merge-strategies

来自：https: //git-scm.com/docs/merge-strategies

The merge mechanism (git merge and git pull commands) allows the backend 'merge strategies' to be chosen with -s option. Some strategies can also take their own options, which can be passed by giving -X arguments to git merge and/or git pull.

ours

This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the 'recursive' merge strategy.

合并机制（git merge 和 git pull 命令）允许使用 -s 选项选择后端“合并策略”。一些策略也可以采用自己的选项，可以通过向 git merge 和/或 git pull 提供 -X 参数来传递这些选项。

我们的

这可以解析任意数量的头，但合并的结果树始终是当前分支头的树，有效地忽略了所有其他分支的所有更改。它旨在用于取代旧的侧枝发展历史。请注意，这与“递归”合并策略的 -Xours 选项不同。

What Bitbucket see later however is a mystery to me, it recognise the commit as merge but fail to actually merge the branch (does not solve a pull-request) - probably Bitbucket guru could help on this issue, I can not even give you any logs/error messages since I do not have that visibility - git/TortoiseGit does not complain at all though.

然而，Bitbucket 稍后看到的对我来说是个谜，它将提交识别为合并但未能实际合并分支（不解决拉取请求） - 可能 Bitbucket 大师可以帮助解决这个问题，我什至不能给你任何日志/错误消息，因为我没有那个可见性 - git/TortoiseGit 根本没有抱怨。

回答by Myridium

The other answers here are basically wrong and wasted my time. A proper answer to this question I found here: https://stackoverflow.com/a/11593308/1351182

这里的其他答案基本上是错误的，浪费了我的时间。我在这里找到了这个问题的正确答案：https: //stackoverflow.com/a/11593308/1351182

git checkout mergeto
git checkout --patch mergefrom [file]

You will then be prompted (file-by-file if you didn't specify file) on exactly which 'hunks' you want to merge. In this way it walks you through each part of what would have been the automaticmerge process and instead asks for manual arbitration on which bits and pieces you want to accept from the mergefrombranch. Here's an example of what it looked like in my project:

然后系统会提示您（如果您没有指定，则逐个文件file）您要合并的确切“帅哥”。通过这种方式，它会引导您完成自动合并过程的每个部分，而是要求手动仲裁您希望从mergefrom分支接受哪些点点滴滴。这是它在我的项目中的外观示例：

@@ -249,7 +251,8 @@ def draw_everything():

     draw_bg()
     draw_balls(ax)
-    plt.show(block=False)
+    if show:
+        plt.show(block=False)

 def advance(ms, accel_fun, collision_matrix_fun):
     global balls
(3/6) Apply this hunk to index and worktree [y,n,q,a,d,K,j,J,g,/,e,?]?

After typing yand <Enter>, I was presented with the next hunk, (4/6)for that file. This prompt at the bottom lets you simply accept the merge 'hunk' with y, reject it with n, or even go in and edit it manually. Here are the options:

输入y和 后<Enter>，我看到了下一个(4/6)文件，用于该文件。底部的这个提示让您可以简单地接受与 合并的“大块头”，与y拒绝它n，甚至进入并手动编辑它。以下是选项：

y - apply this hunk to index and worktree
n - do not apply this hunk to index and worktree
q - quit; do not apply this hunk or any of the remaining ones
a - apply this hunk and all later hunks in the file
d - do not apply this hunk or any of the later hunks in the file
g - select a hunk to go to
/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help

I wanted to go in and manually edit one hunk, as I didn't want to accept or reject the merge exactly as it was posed. So I chose eand was given a file to edit. I was pleased when I noticed there were even instructions at the bottom on how to edit the hunk properly. You can even split hunks into smaller ones with the soption as above.

我想进入并手动编辑一个大块头，因为我不想完全按照它的姿势接受或拒绝合并。所以我选择e并获得了一个文件进行编辑。当我注意到底部甚至有关于如何正确编辑大块的说明时，我很高兴。您甚至可以使用上述s选项将大块头分成较小的块。

I would recommend this process if what you want is manual mergingwhere you still leverage the automatic process as much as possible. The difference is that you get to oversee every merge 'hunk' and edit them as you please. I hope this helps future readers.

如果您想要的是手动合并，而您仍然尽可能多地利用自动过程，我会推荐此过程。不同之处在于您可以监督每个合并“大块头”并根据需要对其进行编辑。我希望这对未来的读者有所帮助。

---

---

The solution I had envisaged (but did not find) was basically to treat every merge hunk as a conflict, and to go in and resolve the conflicts manually. Someone might know how to make this approach work, for example if there is a merge strategy that treats every change as a conflict! Please comment if you find a way to do this. It would be more tedious but perhaps better suited to some people.

我曾设想（但没有找到）的解决方案基本上是将每个合并块都视为冲突，然后手动解决冲突。有人可能知道如何使这种方法起作用，例如，如果有一个将每个更改都视为冲突的合并策略！如果您找到一种方法，请发表评论。它会更乏味，但也许更适合某些人。