将主分支合并到开发分支和将开发分支合并到主分支有什么区别？

Question

我有一个名为master的分支和另一个名为dev的分支。通常，我在dev上进行测试和改进；完成后，我将其合并到master中，标记它，并发布应用程序的新版本。

现在，我面临一个关于合并的决定：

1. 将master合并到dev中
2. 将dev合并到master中

但我不确定这两个有什么区别...任何解释都欢迎。

- sop

---

将一个分支合并到另一个分支不是对称操作；将 master 合并到 dev 与将 dev 合并到 master 是不同的。请参考此示例，差异将变得清晰：https://dev59.com/74Pba4cB1Zd3GeqPtotn#25934341 - jub0bs

使用merge master命令，你可以推进dev分支。 - raina77ow

GIT中的主分支是一个通用名称，意味着这是一个主要的分支，就像SVN中的TRUNK一样。你可以将你的Dev标记为你的主分支，但反之则不行。每次需要开始新的开发迭代时，你需要使用主分支创建新的分支，当你完成这个迭代时，你还需要将你的更改合并或变基到主分支中。你的Dev只是你的开发周期中的一个迭代。 - Anonymous

Answer 1

简述

master和dev分支指向的位置是两者不同之处。

详细解释

将一个分支合并到另一个分支并不是对称的操作：

• 将dev合并到master
• 将master合并到dev

这两个操作通常情况下不是等价的。下面是一个例子，说明了二者之间的区别。假设你的仓库看起来像下面这样：

如果将dev合并到master

如果检出了master（git checkout master），

然后合并dev（git merge dev），你将进入以下情况：

master分支现在指向新的合并提交（F），而dev分支仍然指向合并之前相同的提交（E）。

如果将master合并到dev

如果另一方面检出了dev（git checkout dev），

然后合并master（git merge master），你将进入以下情况：

dev 分支现在指向新的合并提交 (F')，而 master 仍然指向合并之前相同的提交 (D)。

把它们放在一起

- jub0bs

---

“不对称”指的是合并后分支指针指向不同的提交，而提交 F 和 F' 在我的看法中应该是相同的（内容上相同，但 SHA-1 值不一定相同）。 - musiKk

@musiKk 是的，这就是我的意思。我为F和F'使用不同的名称，因为F'是来自平行宇宙的F的邪恶孪生，并且会有一个不同的SHA1值。 - jub0bs

好的！顺便问一下，你用什么来绘制这些漂亮的图片？它们看起来非常像《Pro Git》中的图片... - musiKk

@Jubobs - 我知道你在附录中稍微保留了一下，但你可能需要明确指出两种情况下父级元素是相反的。 - Andrew C

您IP地址为143.198.54.68，由于运营成本限制，当前对于免费用户的使用频率限制为每个IP每72小时10次对话，如需解除限制，请点击左下角设置图标按钮（手机用户先点击左上角菜单按钮）。 - kostix

Answer 2

就我个人而言，我认为被接受的答案对于外行人来说并不足够（如果你一直在寻找这个答案，那么你就是一个 Git 外行人！！）。

@jub0bs 正确地描述了两者之间的技术差异。但他的回答中没有指明应该使用哪一个或为什么要使用它。

当然，总会有例外，但通常情况下，您都会（咳咳）始终将 DEV 合并到 MASTER 中（jub0bs 回答中的方案 b）。

为什么？

要理解为什么，您需要深入挖掘 jub0bs 在对话中提到的高级时间线图之外的内容。因为在两个提交的结尾处，当您查看操作系统目录时，您将无法区分它们之间的区别。因此，幼稚的开发人员会告诉您合并提交的顺序并不重要。

要看到区别，您需要查看 diff 工具（这些工具应该内置在您的 git 客户端中，例如 SmartGit、GitKraken 等）。

让我们想象一下 MASTER 分支上的这个文件：

filename: my_code.txt
some (code) { includes := feature1 + feature2 + feature3; }

而在 DEV 分支中，我们包含了一个漏洞修复：

filename: my_code.txt
some (code) { includes := feature1 + feature2 + bug-fix; }

无论你如何合并提交，最终你会得到以下结果：

filename: my_code.txt
some (code) { includes := feature1 + feature2 + bug-fix + feature3; }

你只会在Git客户端中看到差异。

如果按照方案将MASTER合并到DEV，你的Git客户端会告诉你bug-fix一直作为文件主要历史的一部分存在，并且在某个时刻有人插入了feature3（几乎是事后想起来的）。但是任何一个合格的程序员都会告诉你，从逻辑上讲，这是对历史的错误解释！

真正想做的是将DEV合并到MASTER。在这种情况下，历史记录将告诉你feature1、feature2和feature3一直处于范围内，并计划作为整个项目的主要开发脊梁。而bug-fix则是在路上添加的必要修正（事后或分心）。

- cartbeforehorse