Git 当我将主分支合并到另一个分支时，它是否会被修改？

简单问题：

我最近发现，您可以将

母版

合并到衍生要素

分支

（用最新的

母版

更改更新要素分支）

---

通过这样做，我是否以任何方式修改

主控

？或者它完全没有被那个操作改变？

在这种情况下，您可以在主分支中修改任何内容。您只需将更改从它转移到您的功能分支。 “大师”不是某种“特殊”分支。它只是一个普通的分支，具有相同的规则。它的广泛应用是因为每一个新的git存储库都从一个名为“master”的分支开始，简短的回答是“no”，但这不仅仅是一个简短的回答

如果你从提交的角度而不是从分支的角度来考虑，你会发现你和Git相处得更好。更准确地说，记住哪个分支是当前分支或使用

git status

并查看它是否在分支主控上显示

，或者在分支开发

上显示

，或者在这之后，考虑提交

每个分支名称都指向一个（单个）提交。根据定义，该提交是分支的提示提交。此处指向的短语意味着分支名称字面上包含该提交的原始散列ID。每个提交都有自己唯一的散列ID：任何其他提交都不能有该散列ID。该散列ID表示现在和永远的提交

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

当您这样做时：

git checkout develop

（假设成功），Git通过让
头部记住
develop
的名称，让您“进入”您的
develop
。您当前的提交现在是
开发
名称的提交

当您随后运行时：

git merge master

（假设成功），Git已经完成了合并任何工作的所有工作，这些工作可能会变得复杂，然后可能会进行新的提交。2如果它确实进行了新的提交，则名称
develope
现在标识了新的提交。名称
master
仍然标识名称
master
一直标识的相同提交

同时，每个提交通过其哈希ID引用一定数量的父提交。大多数提交只包含一个父散列ID，因此大多数提交向后指向其一个父散列ID。这一系列向后指向的箭头形成一条链。例如，可能名称
master
包含哈希ID
H
。同时，哈希ID为
H
的提交保存哈希ID
G
，提交
G
保存哈希ID
F
，依此类推：

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

您可以
git checkout
开发以选择commit
J
。（在名字
develope
旁边画一个单词
HEAD
，这样你就可以记住你在
develope
）

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

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

提交
H
未更改，并且名称
master
未移动，因此
master
不受影响


1名称
HEAD
可以包含哈希ID而不是分支名称。在本例中，Git表示您处于“分离头部”模式。诸如创建新提交之类的更新只需将新提交哈希ID直接写入
HEAD
，以便
HEAD
继续分离。使用带有分支名称的
git checkout
将
HEAD
重新附加到该分支名称

2在某些情况下，
git merge
实际上根本不进行合并，而是进行快进操作。这在不需要合并时发生。例如，如果您在
master
上，并且具有以下功能：

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

请注意，这适用于
git checkout master；git merge dev
，而不是相反。做一个
git签出开发；git merge master
将为您提供一条“已经更新”的消息，而其他内容没有任何更改。
正如我在前面的问题中所说的，您通过做比通过问更好。你打算问多少基本的Git问题？如果您将master合并到另一个分支中，为什么要修改master？
...--F--G-----H   <-- master
         \     \
          I--J--K   <-- develop (HEAD)

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

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