假设我们正在使用 git 和拉取请求进行开发，并且我们有：
所以我的问题是：
如果release分支包含Tags，如果release分支在最后一个release/1.x.y版本之后被合并到master中，那么tags是否也被合并了？
对于长期支持，我的问题是：
假设有人想在 10 年内查看标签 1.1.1 的状态。 如果 release 分支被删除但被合并到 master 并且我们有 master ，是否可以检查这个标记的提交？
谢谢
【问题讨论】：
答案是正确的，但有点复杂。这是一个简短的答案：
如果release分支包含Tags，如果release分支在最后一个release/1.x.y版本之后被合并到master中，那么tags是否也被合并了？
标签与分支没有太大关系。它们只指向一个特定的提交——提交在哪个分支中并不重要。
所以是的，合并后标签仍然可用。
对于长期支持，我的问题是：
假设有人想在 10 年内查看标签 1.1.1 的状态。如果 release 分支被删除但被合并到 master 并且我们有 master ，是否可以检查这个标记的提交？
是的。
【讨论】：
1.) 如果发布分支包含标签，并且发布分支在最后一个发布版本之后合并到主 release/1.x.y，标签也合并了吗？
标签不合并，提交（标记或未标记）是。
2.) 对于长期支持，我的问题是：假设有人想在 10 年内检查标签 1.1.1 的状态。可能吗 如果发布分支被删除但检查这个标记的提交 被合并到master中，我们有master？
是的，这不仅是可能的，而且是标签的目的。标签是对特定提交的永久引用，因此这些提交在以后仍可访问以供检查，即使它们没有合并到任何内容中。
【讨论】：
主题行中问题的字面答案——git 标签合并了吗？——是“否”，但这不是一个有趣的答案，因为 分支名称。在 Git 中，通过 commits 进行合并。
您发布的图表还不错，但其中有一些误导性的内容。以下是一些关于它的注释：
其中的箭头指向前方。 Git 不能向前工作； Git向后工作。通常这无关紧要，但就查找提交而言，这很重要。
圆形代表提交。这一切都很好。
有些提交是合并提交，有些提交是普通提交。在这种情况下，所有紫色的feature/* 提交都是普通的，单个bugfix/bug-1 红色的提交也是如此。大多数黄色和绿色提交是合并提交。
由于图中的箭头方向错误——它是向前而不是 Git 的向后——你可以分辨出哪些提交是合并提交，因为它们有多个箭头进入它们。如果箭头绘制正确，即向后，合并提交将是任何具有两个或更多箭头的提交out。
分支名称和标签名称只是标识一个提交。该图在此处具有高度误导性，因为它将名称 master 和 release/1.0.0 放在左侧。如果这些是分支名称，它们确实应该在右侧，指向该分支中的最后一次提交。
Git 利用每次提交的箭头——也就是说，如果箭头绘制正确，将从每次提交中出现的箭头——向后工作 。因此，branch name always 标识了分支中的 last 提交。这意味着名称指向链中的最后一个提交。
标签名称，就像分支名称一样，只是直接指向一个提交。标签名称和分支名称之间的主要区别包括 分支名称会随着时间移动，因此当您添加新提交时，名称会继续指向 last犯罪。因此，如果我们有一个只有三个提交的小型存储库，并且我们使用大写字母（而不是圆形）来代表这些提交，我们可以这样绘制它们：
A <-B <-C <--master
名称master 指向最后一次提交，C。提交C 本身指向更早的提交B，它指向第一个提交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 可以使用嵌入在每个提交中的内部箭头来向后移动历史记录。这意味着如果有提交名称D，如上图所示，Git 可以使用D 来查找C，它可以使用它来查找B，它可以使用它来查找A .因此，这四个提交将保留在此存储库中，因为 D 是可查找的。p>
注意名称master定位commit F，这意味着commit F被保留。提交F定位提交E，定位到D，以此类推；所以这些提交也将被保留。因此有两个名称意味着必须保留D-and-earlier。删除这些名称中的任何一个都会将D-retaining-names 的数量减少到 1，但仍必须保留 D。但是，如果我们删除的名称是master，则不再需要保留提交F。如果 commit F 被抛出，则意味着 commit E 也不再可查找，commit E 也可以被抛出。
如果我们添加另一个名称来查找F，从某种意义上说，删除名称master 是安全的。删除名称 master 实际上会“忘记”master 中的 last 提交当时是提交 F，但提交 F 将是可查找的通过一些其他名称，因此不会被丢弃。
请注意，任何合并提交都有两个（或更多1）箭头出来。如果该合并提交是可找到的，则来自它的箭头将保留所有较早的提交到这些路径中的每一个。因此，一旦您将一些分支提示提交（由某个分支名称标识）合并到您打算保留其名称的其他分支中，删除合并分支的名称是安全的：您将无法找到该提示提交 直接，但您可以通过查找将其作为其额外父提交之一的合并提交来间接找到它哈希 ID。
1Git 将这种合并称为一种合并，它有两个以上的“腿”从其中出来，章鱼合并。这可能就是 GitHub 使用 octocat 作为其 logo 的原因。
【讨论】：
如果你只是将开发分支合并到 Master 你不会丢失标签。标签和分支之间的区别在于标签是特定提交的标记（标签不会随下一次提交移动。反过来，每次提交都会移动分支）。因此，如果您进行合并操作，并使用标签推送提交，您可以返回到带有标签的标签/提交。
您只需要记住将您的标签推送到远程存储库。 Example merge branches with tags
【讨论】：