“合并分支”“开发”和“合并分支”有什么区别？进入功能/tmp”和“合并分支‘开发’” https://github.com/~ 进入 feature/tmp”？

Question

我看到两条合并提交消息 Mergebranch 'develop' into feature/tmp 和 Mergebranch 'develop' of https://github.com/~ into feature/tmp。他们之间有什么区别？

Answer 1

正如其他人在评论中已经说过的那样，您在这里看到的消息只是文本。任何人都可以创建他们喜欢的任何文本。但这两条消息是某些 Git 命令的默认文本。要理解这一点，您必须了解 Git 和提交。

Git 存储库由两个数据库组成：

• 一个数据库保存提交，另一个数据库保存其他内部 Git 对象。
• 另一个数据库保存名称：分支名称、标签名称和其他名称。这些名称可以帮助您（和 Git）找到您关心的提交。

所有 Git 内部对象都是严格只读的，并且在大多数情况下，对象数据库只是您添加的对象。这就是 Git 恢复之前版本的方式：之前的版本位于之前的提交中。您进行新的提交，这会添加新版本。提交是历史记录。¹

提交（以及其他内部对象）都有哈希 ID。任何给定提交的哈希 ID 在每个 Git 存储库中都是完全唯一。这意味着两个不同的克隆（或者实际上是任何两个存储库）可以轻松区分它们与其他克隆的差异：它们共享或共同的提交始终具有相同的内容 哈希 ID。对于他们不共享的提交，一个Git会找到一些哈希IDa123456...或其他什么，而另一个Git不会在找到任何对象全部具有该哈希 ID。

对于您（使用 Git 的人）来说，这意味着哈希 ID 就是提交，具有非常真实且重要的意义。但哈希 ID 的问题是：它们又大又丑，没有人可以直接使用它们。所以我们不这样做：我们使用分支名称来查找提交。这就是第二个数据库的用武之地。

---

¹此历史记录实际上无法更改。当您看到人们谈论“重写历史”时，他们的意思是您添加了新历史，并且新历史不会引用旧的提交（现有历史）。通常，您添加的新历史记录确实会引用旧历史记录。在一对 Git 存储库数据库中，您可以并且确实可以更改的是存储在名称中的值。如果名称 main 让您今天找到提交 a123456，明天提交 b789abc，那么“history”就是您可以通过启动找到的提交集今天在 a123456 处，明天从 b789abc 处开始可以找到一组提交。通常，我们安排b789abc引用回a123456；为了“重写历史记录”，我们根据需要复制尽可能多的原始历史记录到新的和改进的提交，添加我们喜欢的任何其他仅限新的提交，并使 b789abc 引用新的历史记录而不是古老的历史。

此时，旧的历史并没有消失。您只是无法再看到它了。最终，Git 将清理这些完全不可见的提交，前提是 (a) 它们完全不可见，并且 (b) 您不会返回并改变主意并使它们再次可见。

---

分支名称查找提交

分支名称与提交不同，不是唯一的。您的 Git 存储库中可能有一个 main 或 master，我的 Git 存储库中可能也有一个，这两个名称将保存不同提交哈希值身份证。对于任何名称（包括标签名称）都可能如此，但如果我们的两个存储库克隆，我们应该在标签中存储相同的哈希ID名称。 （否则完全可能，但会导致疯狂，或者至少，混乱。不要这样做。）

因为分支名称的定义是它保存最新提交的哈希ID，但是，我们期望不同克隆中的分支名称会随着时间的推移而变化。每次您签出某个分支并进行一些新的提交时，您都会更新您的分支名称的哈希 ID。哈希 ID 查找最新提交。最新提交具有每个提交所具有的内容：

• 提交保存所有源文件的快照，例如 tar 或 rar 或 winzip 存档。 （但是，所包含文件的格式很奇怪并且是特定于 Git 的，这些文件实际上是在提交内和提交之间共享/重用的。这意味着如果您进行新的提交，其中只有一个文件更改，Git 重新使用新快照中除更改的文件之外的所有文件，因此几乎不占用空间。）

• 一次提交保存< em>元数据，或有关提交本身的信息。例如，这包括提交人的姓名和电子邮件地址。它包括一些日期和时间戳。而且，为了让历史记录在 Git 中发挥作用，它包含先前提交的哈希 ID 列表。

大多数提交在其元数据中准确记录了一个先前的提交哈希 ID。这会产生一个简单的向后看的提交链：这就是该分支中的历史记录。 分支名称提供最新提交的原始哈希ID。该最新提交提供了所有文件的快照，以及第二个最新提交的哈希ID。第二个最新提交提供了所有文件的快照，加上第三个最新提交的哈希 ID，其中包含快照和元数据，提供了第四个最新提交的哈希 ID，其中包含快照和元数据......好吧，您现在可能明白了：

... <-F <-G <-H   <--main

如果 main 是我们的分支名称，并且它保存的哈希 ID 是一些大而难看的随机字符串，我们简称为 H，然后名称 main 点提交H。提交H在其元数据中存储了先前提交G的哈希ID（即指向）。提交G 存储更早提交F 的哈希ID，依此类推。

这就是存储库中的历史记录。我们使用分支名称来查找最新提交，然后 Git 为我们反向工作。这就是全部，但这就是我们所需要的。

合并

当我们有几个具有共同历史和各自历史的分支时，如下所示：

          I--J   <-- br1
         /
...--G--H
         \
          K--L   <-- br2

我们可以要求 Git 合并 提交 J 和 L，通过 这样做：

git switch br1 && git merge br2

也就是说，我们首先选择提交 J 作为我们的当前提交，并选择分支名称 br1 作为我们的当前分支嗯>。然后我们告诉 Git：使用名称 b2，查找提交并合并。该名称现在定位提交 L，因此 Git 使用提交J 和 L 来确定分支在之前同步的时间，并执行一些操作简单而愚蠢的面向文本的东西来结合工作在两个分支中完成。

这种组合工作的结果是一个新快照。这个新快照进入新提交，我们在这里将其称为M。新提交以通常的方式进入当前分支：新提交在其元数据中存储当前提交的哈希ID，以便M< /code> 指向 J：

          I--J
         /    \
...--G--H      M
         \
          K--L

合并提交 M 的特殊之处在于，在其元数据中，它列出了两个提交哈希 ID，而不仅仅是一。列表中的第二哈希ID是我们合并的提交的哈希ID，即提交L：

          I--J
         /    \
...--G--H      M   <-- br1 (HEAD)
         \    /
          K--L   <-- br2

Git更新的分支名称，在我们的存储库是 br1，因为这是我们在运行 git merge 之前为 git checkout 或 git switch 指定的分支名称代码>.括号中的名称 HEAD 附加到其中一个分支名称，是显示当前分支名称的一种方式。 当前提交是当前分支名称指向的提交。现在我们已经进行了新的提交 M，Git 已更新 br1，因此 M 现在是分支 br1 上的最新提交。

因为M向后指向两者J和L，全部< /em> 提交现在位于分支 br1 上。因为 br2 指向 L，并且从 L 向后工作找不到提交 M，I< /code> 或 J，此时 br1 上有 3 个提交不在 br2 上。

远程和远程跟踪名称

Git 不仅仅是一个版本控制系统或VCS，而是一个分布式 VCS。在 Git 的例子中，这是通过克隆实现的。我们克隆一个存储库，当我们这样做时，我们会得到其他存储库的所有提交，并且没有任何分支。

也就是说，假设某个other存储库有一个main和一个develop：

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

我们运行git clone url。我们的 Git：

• 以 Git 调用远程的名称保存 URL；
• 创建一个新的、完全空的存储库：两个数据库都是空的；
• 连接到响应给定 URL 的任何人：这应该是某个 Git 软件，连接到 Git 存储库，我们将该组合称为“他们的 Git”；
• 从他们的 Git 中获取所有分支名称的列表以及相应的提交哈希 ID；
• 使用这些哈希 ID 来获取他们的提交，包括他们的历史记录（所有早期提交）；
• 获取所有分支名称并重命名，并在我们存储库中创建重命名名称。

为了构建新名称，我们的 Git 软件会采用它们的分支名称并将远程名称放在前面。标准的第一个远程名称是origin。因此，远程 origin 为我们做了两件事：

• 保存 URL，以便我们将来可以随时再次联系他们的 Git；它
• 提供了远程跟踪名称前缀：他们的main成为我们的origin/main，他们的develop成为我们的起源/发展。

这些远程跟踪名称的功能类似于分支名称 - 它们找到最新提交 - 但它们实际上并不是分支名称。我们无法git switch到它们。所以现在我们的存储库中有这个：

...--F--G--H   <-- origin/main
         \
          I--J   <-- origin/develop

但从某种意义上说，我们自己的 Git 软件想要“在分支上”。为了进入一个分支，我们的 Git 现在必须创建一个分支名称。我们的 Git 将创建什么分支名称？答案分为两部分：

1. 我们的 Git 将在命令行上使用 -b 选项创建我们告诉它的分支名称。
2. 如果我们没有使用 -b（而且我们也没有使用），我们的 Git 会询问他们的 Git 他们推荐哪个名称。此处可能是 main 或 develop，因为它们是它们拥有的两个分支名称。他们推荐 main 是很典型的。

因此，考虑到所有这些，我们的 Git 现在可能会创建 main 。我们的名称 main 将指向哪个提交？答案是：现在，他们的名称所指向的提交相同，我们已将其以名称 origin/main 存储在本地。所以我们得到：

...--F--G--H   <-- main (HEAD), origin/main
         \
          I--J   <-- origin/develop

请注意，我们现在有两个名称指向提交H。没关系！一次提交可以有任意多个名称。每个名称要么是一个分支名称（例如此处的main），要么是某种其他类型的名称（例如此处的远程跟踪名称）。 分支名称是我们可以给git switch的名称，以“进入”分支，之后我们所做的任何新提交都会前进指向新提交的分支名称，它将指向当时最新的提交。因此，如果我们坚持使用 main 并进行新的提交，我们会得到：

             K   <-- main (HEAD)
            /
...--F--G--H   <-- origin/main
         \
          I--J   <-- origin/develop

本地合并与 git pull

要进行纯粹的本地合并，我们：

• 按名称切换到某个分支，然后
• 运行 ​​git merge 并为合并命令提供分支名称或任何其他方式来查找任何提交。

只要其他提交是 Git 可以合并的内容，Git 就会进行合并（或者不进行合并 - 例如，git merge 有选项使其执行常规合并以外的操作，并且有一些默认值）并不总是合并的操作 - 但我们在这里假设我们得到了真正的合并）。新的合并提交是一个提交，因此它具有快照和元数据。元数据包括日志消息。

当您运行 git merge 且 Git 进行新合并时，Git 默认情况下会在带有合并消息的文件上打开编辑器。合并消息是您告诉人们为什么执行此 git merge 命令的地方。不过，大多数人都不会打扰。他们只是让 Git 使用其蹩脚的默认合并消息。 默认合并消息是：

Merge branch 'develop'

或：

Merge branch 'develop' into feature/tmp

左侧单引号中的名称，在本例中为 'develop'，是我们为 git 指定的名称合并命令。当我们位于名为 feature/tmp 的分支时，into feature/tmp 部分就会出现；如果我们不在 main 分支上，则默认显示 into 部分，无论它是什么（master 或 main，现在是可配置的；在旧版本的 Git 中，master 是唯一这样被省略的）。

这条默认消息不太好。它如此乏味的原因是分支名称​​随着时间的推移而变化，以指向新的提交。如果您感觉精力充沛，您可以将其更改为，例如：

Merge Bob's update to incorporate the new foobler software,
because our feature development needs to foo some bars.

然而，实际上，正如我之前所说，似乎没有人打扰。 （您或进行此合并的任何人显然也没有打扰。）

现在，如果您在 feature/tmpgit mergedevelop ，就会发生这种情况>。但是如果你运行：

git pull origin develop

？在本例中，您使用的是 git pull 便捷命令。该命令是运行两个 Git 命令的缩写：

1. git fetch；然后
2. 是您选择的命令，通常配置一次，然后从现在开始使用。

步骤 2 中的默认命令是 git merge。这似乎是您的设置：默认设置，即您从未将 git pull 配置为运行不同的东西。 （有些团体更喜欢使用 rebase 而不是 merge，但这是个人喜好问题：偏好 rebase 有有效的论据，也有偏好合并的有效论据。Git 默认为 merge，这至少简单 rebase。）

每当您直接运行 git fetch 或通过 git pull 运行时，您的 Git 都会连接到另一个 Git（该软件在保存的 URL 上进行响应，使用保存的存储库指示网址）。您的 Git 从他们的 Git 获取您没有但需要的任何新提交。² 然后，您的 Git 会更新您的 origin/在您自己的存储库中开发。³因此，如果您有，请说：

       J--K   <-- feature/tmp (HEAD)
      /
...--H   <-- main
      \
       I   <-- origin/develop

在 git fetch 步骤之前，以及：

       J--K   <-- feature/tmp (HEAD)
      /
...--H   <-- main
      \
       I--L   <-- origin/develop

在 git fetch 之后> git pull 的步骤，这意味着他们自上次 git fetch 以来，向他们的存储库添加了一个提交（我们在此称为 L 的提交）。现在，您的存储库中也有该提交，并且您的 origin/develop 现在指向该特定提交。

您的 Git 软件现在运行命令二，以完成 git pull。在本例中，第二个命令是 git merge，因此您的 Git 会进行常规合并，这会生成一个新的合并提交 M：（

       J--K
      /    \
...--H      M   <-- feature/tmp (HEAD)
      \    /
       I--L   <-- origin/develop

我停止在名称中绘制 main，但它仍然在那里，指向提交 H：现在很难绘制）。

新的合并提交M在其元数据中有一条日志消息。与您可能亲自运行的git merge命令一样，Git通常会给您一个机会编辑此日志消息并添加更好的内容，但 Git 提供了一个蹩脚的默认值。不过，默认值不是来自 git merge，而是来自 git pull。 git pull 命令知道您刚刚从通过名称 存储的 URL 获取了最新 develop起源。因此，您的 git pull 会生成默认的相当蹩脚的日志消息：

Merge branch 'develop' of <url> into feature/tmp

部分是来自 origin 的部分； develop 是您给 git pull 的参数，即提交他们的 Git 的 develop 已识别，通过 git fetch 传输 - 如果您不在主分支上，则像往常一样添加 into 部分，而您不在主分支上。

您（或进行此合并的任何人）接受了这个不太好的默认提交消息（就像大多数人所做的那样），所以这就是您得到它的方式。

---

²当您不带任何参数运行 git fetch 时，您的 Git 会从其 Git 所有分支获取并创建或更新以通常的方式列出您的所有远程跟踪名称。您可以告诉git fetch将其获取的内容限制为一个分支所需的内容，并且git pull有时会做这个。在这种特殊情况下，git pull origindevelop 指示 git fetch 带来新的 develop 提交，然后仅更新您自己的 起源/发展。

³Git 1.8.4 之前的 Git 版本无法在这些有限获取的情况下更新远程跟踪名称。要解决这个问题，请确保您没有使用旧版本的 Git。

---

底线

无论谁通过运行 git merge 在本地进行合并，都让 Git 使用其默认合并消息。

无论是谁通过运行 git pull 在本地进行合并，都让 Git 使用其默认合并消息。

由于分支名称总是在演变，因此这两条消息都没有多大价值。 pull 消息确实告诉您，无论是谁执行此操作，都使用特定的 GitHub 克隆作为他们合并的提交的源。这些信息是否有任何价值可能只能根据个人情况来回答。