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

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

有更简单的方法：

git merge --no-commit merge_branch

正如男人所说：

通过--no-commit执行合并但假装合并失败并且不自动提交，使用户有机会在提交之前检查并进一步调整合并结果。

我有一个场景，其中：

git merge --no-commit merge_branch 

只是造成了快进。

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

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

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

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

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

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

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

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

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

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

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

git difftool other_branch

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

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

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

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

可能有人会纠正我，但是除了N向合并功能之外，这两种方法似乎产生相同的结果。既不difftool也不mergetool在其他提交上添加other_branch作为父提交，因此在两种情况下，合并在gitk中都不明显，因此必须在提交消息中进行描述（并在以后进行注意）。

我发现其他答案不尽​​人意，因此沮丧地寻找答案。我终于在这里找到这个问题的解决方案：https : //stackoverflow.com/a/11593308/1351182

git checkout branchToMergeTo
git checkout --patch branchToMergeFrom [file]

然后，系统会提示您（如果未指定，则逐个文件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,?]?

在输入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

我想进入并手动编辑一个大块，因为我不想完全按照所接受的方式接受或拒绝合并。因此，我选择e并给了一个文件进行编辑。当我发现底部甚至还包含有关如何正确编辑大块的说明时，我感到很高兴。您甚至可以使用上述s选项将大块拆分为较小的大块。

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

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

在进行手动比较之后，我选择了我们的策略（在TortoiseGit中也作为策略存在），在其中您手动引入了所需的更改。

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

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

我们的

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

然而，Bitbucket后来看到的东西对我来说还是个谜，它将提交确认为合并，但未能真正合并分支（不能解决请求请求）-也许Bitbucket专家可以解决这个问题，我什至无法给您任何帮助日志/错误消息，因为我没有这种可见性-git / TortoiseGit一点也不抱怨。