git标签合并了吗？

Question

让我们假设我们正在使用 git 和 pull requests 进行开发，我们有：

1. 一个主分支
2. 一个 release/1.... 分支，对于每个修补程序或功能，还有一个分支，在接受拉取请求后合并到起始分支中。

所以我的问题是：

1. 如果发布分支包含标签，并且发布分支在最后发布的 release/1.xy 版本之后被合并到 master 中，那么标签是否也被合并了？

2. 对于长期支持，我的问题是：

   假设有人想在 10 年内检查标签 1.1.1 的状态。如果 release 分支被删除但被合并到 master 并且我们有 master ，是否可以检查这个标记的提交？

谢谢

Answer 1

1.)如果release分支包含Tags，并且如果在release/1.xy的最后一个发布版本之后release分支被合并到master中，那么tags是否也被合并？

标签不会合并，提交（标记或未标记）会合并。

2.)对于长期支持，我的问题是：假设有人想在 10 年内检查标签 1.1.1 的状态。如果发布分支已删除但已合并到主分支并且我们拥有主分支，是否可以检查此标记的提交？

是的，这不仅是可能的，而且也是标签的目的。标签是对特定提交的永久引用，因此即使这些提交没有合并到任何内容中，以后也可以进行检查。

Answer 2

主题行中问题的字面答案——git 标签是否合并？— 是“否”，但这不是一个有趣的答案，因为分支名称也不是。合并，在 Git 中，通过提交工作。

您发布的图表还不错，但其中有一些具有误导性的内容。这里有一些关于它的注意事项：

• 其中的箭头指向前方。Git 不能向前工作；Git 反向工作。通常这并不重要，但就查找提交而言，这很重要。

• 圆圈代表提交。这一切都很好。

• 有些提交是合并提交，有些提交是普通提交。在这种情况下，所有紫色feature/*提交都是普通的，单个bugfix/bug-1红色提交也是如此。大多数黄色和绿色提交都是合并提交。

  由于图中的箭头方向是错误的——它们是向前的，而不是 Git 的向后——你可以分辨哪些提交是合并提交，因为它们有不止一个箭头进入。有箭头被正确地绘制，即向后，合并提交将任意两个或更多的箭头未来犯下了这一点。

• 分支名称和标签名称只是标识一次提交。该图在此处具有高度误导性，因为它将名称master和release/1.0.0放在左侧。如果这些是分支名称，它们确实应该在右侧，指向该分支中的最后一次提交。

  Git的利用即将出来的箭头每次提交-即，箭头将未来各出提交，如果箭头已经拟定正确，工作倒退。因此，分支名称 始终标识分支中的最后一次提交。这意味着名称指向链中的最后一次提交。

标签名称，就像分支名称一样，直接指向一个提交。标记名称和分支名称之间的主要区别包括分支名称随时间移动的事实，因此当您添加新提交时，名称继续指向最后一次提交。因此，如果我们有一个只有三个提交的小型存储库，并且我们使用大写字母（而不是圆形）来代表这些提交，我们可以像这样绘制它们：

A <-B <-C   <--master

名称master指向最后一次提交，C. CommitC本身指向较早的 commit B，它指向 very-first commit A。（因为A是第一次提交，它只是没有指向任何地方，这就是 Git 知道停止遍历的方式。）

添加一个新的提交——我们称之为D——Git 写出新的提交，以便它指向现有的提交C，它曾经是分支上的最后一个提交。然后 Git 将D的实际哈希 ID写入name master：

A <-B <-C <-D   <--master

如果标记名称指向这些提交之一，则该标记名称保持原样：

A <-B <-C <-D   <--master
            ^
            |
         tag:v11

当我们添加一些新的提交时，我们得到：

A <-B <-C <-D <-E <-F   <--master
            ^
            |
         tag:v11

标签名称没有移动，也不应该移动。（您可以手动“移动”一个，删除它并创建另一个同名的，或使用强制选项之一，但通常不应该这样做。）

如果发布分支被删除，是否可以检查这个标记的提交......

当然。分支名称、标签名称和其他名称用于定位一个特定的提交。您可以使用该名称直接转到该提交。只要名称本身继续存在，提交本身就会保留在该 Git 存储库中。

找到某个提交（通常是通过名称）后，Git 可以使用嵌入在每个提交中的内部箭头在历史中向后移动。这意味着如果 commit 有一个名称D，如上图所示，Git 可以使用Dfind C，它可以使用 find B，它可以使用 find A。这四个提交因此将保留在此存储库中，因为它们D是可查找的。

请注意，名称master位于 commit F，这意味着F保留提交。CommitF定位 commit E，它定位D，依此类推；所以这些提交也将被保留。因此，有两个名称表示D必须保留 -and-earlier。删除这些名称中的任何一个都会将D-retaining-names的数量减少到 1，但D仍必须保留。master但是，如果我们删除的名称是，F则不再需要保留提交。如果 commitF被抛出，那意味着 commitE也不再可找到，并且 commitE也可以被抛出。

如果我们添加另一个名称 find F，从某种意义上说，删除 name 就变得安全了master。删除名称master实际上将“忘记”最后一次提交master此时是 commit F，但提交F将可以通过其他名称找到，因此不会被抛出。

请注意，任何合并提交都有两个（或多个¹）箭头出来。如果该合并提交是可找到的，则来自它的箭头会保留所有这些路径中的所有较早提交。因此，一旦您将某个分支名称所标识的分支提示提交合并到您打算保留其名称的其他分支中，就可以安全地删除合并分支的名称：您将无法直接找到该提示提交，但您可以通过查找将其作为其额外父提交哈希 ID之一的合并提交来间接找到它。

¹ Git 将这种合并称为octopus merge，这种合并具有两条以上的“腿” 。这可能就是 GitHub 使用octocat作为他们的标志的原因。