当我将主分支合并到另一个分支时，它会被修改吗？ [复制]答案

【问题标题】：Does the master branch gets modified when I merge it into another branch? [duplicate]当我将主分支合并到另一个分支时，它会被修改吗？ [复制]
【发布时间】：2019-10-31 09:52:09
【问题描述】：

简单的问题：

我最近发现您可以将您的 master 合并到派生功能 branches（以使用最新的 master 更改更新您的功能分支）。

这样做，我是否以任何方式修改了master？还是完全没有被那个操作改变？

【问题讨论】：

就像我在你之前的问题中所说的那样，你通过实践比通过提问学得更好。你打算问多少个基本的 Git 问题？如果将master合并到另一个分支中，为什么要修改master？

标签： git git-branch git-merge

【解决方案1】：

简短的回答是“不”，但这不仅仅是一个简短的回答。

如果您从 commits 的角度而不是分支的角度考虑，您会发现您和 Git 相处得更好。好吧，更准确地说，重要的是要记住哪个分支是当前分支——或者使用git status，看看它是on branch master还是on branch develop或者其他——但是之后 em> 那一点，考虑提交。

每个分支名称都指向一个（单个）提交。根据定义，该提交是分支的 tip 提交。此处的短语 points to 表示分支名称实际上包含该提交的原始哈希 ID。每个提交都有自己唯一的哈希 ID：没有其他提交可以拥有该哈希 ID。该哈希 ID 意味着那个提交，现在和永远。

特殊名称HEAD指的是一个分支名称。¹即HEAD记住一个分支名称，一个分支名称记住一个提交。

当你这样做时：

git checkout develop

（假设它成功了），Git 通过让 HEAD 记住名称 develop，让你“使用”你的 develop。您当前的提交现在是develop 命名的那个。

当您随后运行时：

git merge master

（假设它成功了），Git 已经完成了所有的合并工作——无论是什么工作，这可能会变得复杂——然后可能会进行新的提交。² 如果它做到了 进行新的提交，名称 develop 现在标识新的提交。名称 master 仍然标识名称 master 一直标识的相同提交。

同时，每个提交通过它们的哈希 ID 引用一定数量的 parent 提交。大多数提交只保存一个父哈希 ID，因此大多数提交向后指向它们的一个父级。这一系列向后指向的箭头形成了一条链。例如，名称 master 可能包含哈希 ID H。同时，hash ID为H的commit持有hash IDG，commitG持有hash IDF，以此类推：

... <-F <-G <-H   <-- master

Git 可以从名称 master 到提交 H，然后返回到 G，再到 F，依此类推，在提交链中倒退。

没有任何提交可以永远改变 - 一点也不 - 所以一旦提交存在并且有一些父母，该提交总是会向后指向这些父母。（您无法更改提交。最多可以让 Git 停止查看提交。如果您和 Git 都无法找到提交，则提交最终会从存储库中退出并被垃圾回收.) Git 主要只是不断地向链中添加 new 提交。

所以我们从这样的开始：

...--F--G--H   <-- master
         \
          I--J   <-- develop

你git checkout开发选择提交J。（在名字develop旁边画上HEAD这个词，这样你就可以记住你在develop上。）

现在您运行git merge master，Git 启动了合并机制。这会进行大量计算，以找出正确的合并结果，并构建一个新的提交。由于新的提交是一个合并提交，它像往常一样指向J，但也指向H：

...--F--G-----H   <-- master
         \     \
          I--J--K

作为写出合并提交K 的结果，Git 将其哈希 ID（无论它实际上是什么）写入 HEAD 所附加的名称，现在 develop 指向提交 K：

...--F--G-----H   <-- master
         \     \
          I--J--K   <-- develop (HEAD)

提交H 没有改变——它不可能是——并且名称master 没有移动，所以master 不受影响。

¹名称HEAD可以包含哈希 ID 而不是分支名称。在这种情况下，Git 说您处于“分离 HEAD”模式。更新——例如创建新的提交——只需将新的提交哈希 ID 直接写入HEAD，以便HEAD 继续分离。使用带有分支名称的 git checkout 将 HEAD 重新附加到该分支名称。

²在某些情况下，git merge 实际上根本不进行合并，而是进行快进操作。当不需要合并时会发生这种情况。例如，如果你在master 上并且有这个：

...--G--H   <-- master (HEAD)
         \
          I--J  <-- dev

并询问git merge dev，如果要进行真正的合并，Git 必须合并的更改将是从提交 H 到提交 H 的任何更改（@@ 上的“你更改的内容” 987654375@) 从提交 H 到提交 J 的任何更改（dev 上的“他们更改的内容”）。但很明显，提交H 中的内容与提交H 中的内容相同。实际上不需要进行任何合并！如果您允许，git merge 根本不会费心去合并，而是直接检查提交 J并将名称 master 向前拖动以匹配，给出：

...--G--H
         \
          I--J  <-- dev, master (HEAD)

请注意，这是针对git checkout master; git merge dev，而不是相反。发送git checkout dev; git merge master 会给你一个“已经是最新的”消息，而没有其他任何改变。

【讨论】：

【解决方案2】：

在这种情况下，您在 master 分支中修改 nothing。您只需将更改从它更改到您的功能分支。 “master”不是某种“特殊”分支。它只是一个具有相同规则的普通分支。而且它的普及是因为每个新的 git 存储库都以一个名为“master”的分支开始

【讨论】：