git merge origin/master 是什么意思？

Question

执行git fetch从远程获取后，我们需要使用类似下面的命令：

git merge origin/master

我想知道这个命令是否同时执行git commit？origin/master的顺序很重要吗？我可以写成master/original吗？

- Adam Lee

---

你真的应该通读这本书中的Git分支和远程分支章节。 - kostix

Answer 1

git merge origin/master 可以执行以下两种操作（或出错）。

第一种情况是，它会创建一个新的提交记录，该记录有两个父节点：当前的 HEAD，以及由引用 origin/master 指向的提交记录（除非您正在进行某些有趣的操作，否则这很可能是指一个名为 master 的分支在名为 origin 的远程仓库上的本地指针，尽管这完全是常规操作）。

在第二种情况下，不需要进行树级合并，而是更新当前检出的引用，使其指向与 origin/master 所指向的提交相同的提交。（这称为快进合并 —— 通过命令行标志，可以指示 git 在合并时始终执行此操作或永远不执行此操作）。

它不直接调用 git commit 命令，该命令是面向用户的更高级别（在 git 术语中称为瓷器）命令。

调用 git merge master/original 将尝试将 master/original 解析为提交记录，这几乎肯定（再次强调，除非您有意进行某些操作）与 origin/master 不同。如果您恰好有一个名为 master，带有名为 original 的分支的远程仓库，则它将创建一个新的提交记录，该提交记录将该记录作为第二个父节点。

您可能会发现git help rev-parse 在解密 git 如何将引用名称或其他标记解析为提交记录方面很有帮助。

- Matt Enright

Answer 2

这个操作会将被称为 origin/master 的分支合并到你当前所在的分支中。顺序非常重要。单词 origin 意味着你克隆代码库时使用的源，即代码库的来源；单词 master 只是一个分支名，但通常用作主分支或一些其他系统称之为 trunk 分支。

根据你的开发状态，合并可能需要进行提交。如果你的历史记录没有与源发生分歧，则可以执行所谓的 fast-forward，只需将新历史记录放在你的历史记录之上即可。如果你的开发已经与源分歧，则如果合并可以无冲突地完成，则会进行合并，并在 HEAD 处记录一个新的提交来指定合并和两个父提交。

此外，如果由于冲突而无法执行合并，则你的工作副本将更新以反映存在冲突的事实，然后当你修复它们时，你需要手动进行提交以记录合并。

- Jarryd

---

你的答案有两个地方是不正确的。首先："将当前分支与称为origin/master的分支合并"是不正确的，因为origin/master被合并到当前分支中。或者这可能是我在这个地方看到的歧义，那么请澄清一下。其次，git merge在某些情况下确实会执行提交（例如，当没有明确告知不执行提交且可以通过快进方式执行合并时）。 - Tadeck

是的，那就是我的意思，我已经修正了措辞。你是说快进实际上和提交是一样的吗？我原本以为快进更像是将新的开发历史与自己的历史拼接在一起。 - Jarryd

请查看此链接：http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_description - 特别是这一句："_(...) git merge topic 将会重放自从它与 master 分支分叉后，topic 分支上所做的更改(...) 直到其当前提交在 master 的顶端，并将结果记录在新提交中，同时附带两个父提交的名称和来自用户描述更改的日志消息。" 我相信这很清楚。它确实执行提交（除非首先检测到某些冲突并且需要解决它们）。 - Tadeck

啊，我明白了。但是只有在你的开发分支与主分支不同步时才会进行提交，而不是可以使用快进方式完成的情况下。文档中说：“在这种情况下，不需要创建新的提交来存储合并后的历史记录；相反，将更新HEAD（以及索引）以指向命名的提交，而不创建额外的合并提交。”我会修正我的回答。 - Jarryd

也许在你不想创建提交时，使用--no-commit会更安全一些（http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_options）。 - Tadeck