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

有更简单的方法：

git merge --no-commit merge_branch

正如男人所说：

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

---

我有一个场景：

git merge --no-commit merge_branch 

只是引起了快进。

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

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

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

---

一个类似的问题是How to prevent an automerge using git?

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

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

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

---

对于只需要对合并进行微观管理的任何人，请跳至下面的混合部分。

如果有人想知道 @True 使用 git difftool 的答案与使用 git merge 的其他答案之间的区别，请参阅 Git mergetool vs difftool。

以下是更多详细信息：

差异工具

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

git difftool other_branch

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

合并工具

其他答案讨论的“正确”方式是将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。如果您使用 git 已经知道的工具之一，那么您根本不需要配置 mergetool.*.cmd 条目。 （Meld 只能显示三个窗格，因此如果使用默认设置的 meld，您将看不到 $BASE。）

差异工具与合并工具

有人可能会站出来纠正我，但上述 difftool 和 mergetool 技术之间的主要区别似乎是：

如果相应配置，mergetool 可以进行 N 路合并

mergetool 在新提交中添加 other_branch 作为父级，因此历史记录可以正常工作

difftool 让您可以手动查看和选择每个更改的行，但是您失去了 mergetool 的上述两个好处

混合动力——两全其美

结合合并和差异的方法看起来像这样：

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

...这会进行 N 路合并以解决冲突并使历史记录正常工作，然后向您显示完整的差异集，以便您可以在提交之前查看和调整。

---

我发现其他答案不令人满意，并且在寻找答案时感到沮丧。我终于在这里找到了这个问题的解决方案：https://stackoverflow.com/a/11593308/1351182

如果您运行这些命令，您将创建一个新的提交，它基本上采用 branchToMergeFrom 的最新提交，并允许您在其上应用补丁，我认为这就像在顶部的附加提交。

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 接受合并“hunk”，用 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 选项将大块分割成更小的块。

如果你想要的是手动合并，我会推荐这个过程，你仍然尽可能地利用自动过程。不同之处在于您可以监督每个合并“大块”并随意编辑它们。我希望这对未来的读者有所帮助。

在此过程之后，您可能希望运行 git checkout branchToMergeTo && git merge branchToMergeFrom 以便将 branchToMergeFrom 的历史正式合并到 branchToMergeTo 中。

---

请注意，如果您坚持手动合并（可能针对某一类文件），您仍然可以定义一个合并驱动程序。
“Git - how to force merge conflict and manual merge on selected file”中有一个具体示例。

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

---

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

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

合并机制（git merge 和 git pull 命令）允许使用 -s 选项选择后端“合并策略”。一些策略也可以采用自己的选项，可以通过将 -X 参数传递给 git merge 和/或 git pull 来传递。 ours 这解决了任意数量的头，但合并的结果树始终是当前分支头的树，有效地忽略了所有其他分支的所有更改。它旨在用于取代分支的旧开发历史。请注意，这与“递归”合并策略的 -Xours 选项不同。

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

---