git合并的方式是什么？答案

【问题标题】：which way to git merge?git合并的方式是什么？
【发布时间】：2015-09-28 20:17:56
【问题描述】：

假设我想将分支featureBranch 进行非快进合并（“真正的合并”，绝对不是变基）到分支master。为简单起见，请假设没有远程仓库（只有 1 个本地仓库），这是git checkout featureBranch && git log 的输出：

Switched to branch 'featureBranch'
commit 486b01a6db4597a8f02c9f23a16ddaa2d0e18392
Author: xxx <xxx@xxx.com>
Date:   Mon Sep 28 21:02:00 2015 +0100

    C

commit 39fde8a6ccd27ad8e5b815f5462ae6267df2e213
Author: xxx <xxx@xxx.com>
Date:   Mon Sep 28 21:00:34 2015 +0100

    A

这是git checkout master && git log的输出：

Switched to branch 'master'
commit 903ad86a4395f004dd2f28009b11f93d4c056d0b
Author: xxx <xxx@xxx.com>
Date:   Mon Sep 28 21:00:54 2015 +0100

    B

commit 39fde8a6ccd27ad8e5b815f5462ae6267df2e213
Author: xxx <xxx@xxx.com>
Date:   Mon Sep 28 21:00:34 2015 +0100

    A

是这样进行合并的正确方法：

git checkout master && git merge featureBranch

或类似：

git checkout featureBranch && git merge master

请注意，这不是 this SO question 的复制品，它是关于快进合并的。

【问题讨论】：

标签： git version-control merge

【解决方案1】：

正确的做法是：

git checkout master
git merge featureBranch

原因是合并中父提交的顺序很重要，并且master应该始终是两者中的第一个。这确保git log --first-parent 的行为符合预期。此博文中的更多详细信息：http://devblog.nestoria.com/post/98892582763/maintaining-a-consistent-linear-history-for-git

marcolz 提出的方法会破坏日志，因为它会创建 2 个合并提交，其中第一个具有功能分支的最后一次提交（它应该在第二个）。

乔纳森的回答基本上是正确的，但缺乏博文中的细节。

【讨论】：

是的，这对于小的非冲突合并是可以的。我们倾向于同时开发几个功能分支。这意味着当一些分支同时合并到 master 时，你的合并到 master 的机会将会减少。那时没有线性历史这样的东西。然后，您会不时将 master 合并回您的 dev 分支，以便随时随地解决您的 dev 分支中的冲突，因此最终合并到 master 将很容易。在这种情况下，线性历史也不会增加太多清晰度。
您可以使用 merge --squash 进行最终合并到 master 以在您描述的情况下将线性历史记录保留在 master 上（一个长期存在的分支）。
据我所知，合并一种方式和合并另一种方式之间的唯一区别在于提交对象中列出了父提交的哪个顺序？这意味着它不仅会破坏git log --first-parent，还会破坏master~5、HEAD^^^等。

【解决方案2】：

最常见的是合并到你当前所在的分支中。

所以：

git checkout master
git merge featureBranch

不要忘记 reflog...如果你曾经合并并意识到你犯了一个错误（在推送之前），你可以将你的分支重置到它的前一点。见Undo a Git merge that hasn't been pushed yet

【讨论】：

我一直认为这是一个正确的答案，但我认为我需要一个更好的证明。我想我隐约记得在 git 邮件列表上看到了一个具体的原因，关于将 master 合并到不同的分支中破坏了 git log 的某些行为......“这是最常见的”并不是一个非常周到的理由。
@AdamKurkiewicz “破坏 git log 的某些行为”也许他们指的是使用“git merge”时可以创建的合并提交。使用合并方法将您的工作集成到 master 中肯定会创建一个难以管理的提交“蜘蛛网”。我仍然会断言我的答案是“最标准”的方式，但您可能想看看“rebase”命令
我已经回忆起如果合并方向错误会中断是什么。这是 git log --first-parent。看看我的回答！

【解决方案3】：

最好先将要合并的分支合并到特性分支中，以解决特性分支中可能存在的冲突。

git checkout featureBranch && git merge master

当冲突解决后，您就可以安全地做：

git checkout master && git merge featureBranch

要强制进行非 ff 合并，您可以传递 --no-ff

【讨论】：

我最好的猜测是，这是个坏建议。我想我隐约记得在 git 邮件列表上看到了一个特定的原因，关于将 master 合并到不同的分支中破坏了 git log 的某些行为...
好吧，在这种特殊情况下，它是不需要的，因为分支只有 1 次提交长（短），但是如果你有一个长期存在的并行特性分支，以便跟上提交给 master 的更改，您要么需要使用我描述的方法，要么继续将 featureBranch 重新定位在 master 上。如果你不关心你的 featureBranch 的历史（就像你说它只是本地的），那将是首选。在这种情况下，您可以跳过将 master 合并到 featureBranch 中。如果其他人也克隆了 featureBranch，那当然是个问题。
我做了更多的挖掘工作，我挖出了一篇非常有用的博客文章，它解释了为什么git checkout master && git merge featureBranch 是正确的方法。检查我的答案！