git 个标签合并了吗？
Are git tags merged?
假设我们正在使用 git 和拉取请求进行开发，并且我们有：
- 一个主分支
- 一个release/1..分支
对于每个修补程序或功能，还有一个分支，在接受拉取请求后合并到起始分支中。
所以我的问题是：
如果release分支包含Tags，如果release分支在release/1.x.y的最后一个发布版本之后合并到master中，那么tags是否也合并了？
对于长期支持，我的问题是：
假设有人想查看 10 年后标签 1.1.1 的状态。
如果 release 分支被删除但合并到 master 并且我们有 master ，是否可以检查这个标记的提交？
谢谢
1.) If the release branch contains Tags and if the release branch is merged into the master after the last released version of
release/1.x.y, are the tags also merged?
标签未合并，提交（标记或未标记）合并。
2.) And for long term support my question is: Lets assume somebody wants to check out the state of tag 1.1.1 in 10 years. Is it possible
to check out this tagged commit if the release branch was deleted but
was merged into the master and we have the master ?
是的，这不仅是可能的，而且是标签的真正目的。标签是对特定提交的永久引用，因此这些提交以后仍可访问以供检查，即使它们没有合并到任何东西中。
如果你只是将开发分支合并到 Master，你不会丢失标签。标签和分支之间的区别在于标签是特定提交的标记（标签不会随着下一次提交而移动。反过来，分支会随着每次提交而移动）。因此，如果您进行合并操作，并使用标签推送提交，您可以返回到带有标签的 tags/commits。
您只需要记住将标签推送到远程存储库即可。
Example merge branches with tags
您主题行中问题的字面答案——git 标签合并了吗？——是“否”，但这不是一个有趣的答案，因为两者都不是是 分支名称 。合并，在 Git 中完成 提交 .
您张贴的图表还不错，但其中有一些东西具有误导性。这里有一些关于它的注释：
里面的箭头指向前方。 Git 不向前工作； Git 向后工作。通常这无关紧要，但就发现 提交而言，这很重要。
圆圈代表提交。一切都很好。
一些提交是合并提交，一些提交是普通提交。在这种情况下，所有紫色 feature/* 提交都是普通的，单个 bugfix/bug-1 红色提交也是如此。大多数黄色和绿色提交都是合并提交。
由于图中的箭头方向错了——它们向前而不是 Git 的 backwards-ness——你可以分辨出哪些提交是合并提交，因为它们有多个箭头来到他们身边。如果箭头被正确绘制，即向后，合并提交将是任何带有两个或更多箭头的提交 out。
分支名称和标签名称仅标识一个 提交。该图在这里具有很大的误导性，因为它将名称 master 和 release/1.0.0 放在了左侧。如果这些是分支名称，它们确实应该在右边，指向该分支中的最后一次提交。
Git 利用了每次提交的箭头——也就是说， 将 来自每次提交的箭头，如果箭头正确绘制 - 工作 向后 。因此 分支名称 总是 标识分支中的 last 提交。这意味着该名称指向链中的最后一次提交。
标签名称，如分支名称，直接指向一个提交。标记名称和分支名称之间的主要区别包括 分支名称随时间移动 ，因此当您添加新提交时，名称继续指向 最后 提交。因此，如果我们有一个只有三个提交的小型存储库，并且我们使用大写字母（而不是圆圈）来代表这些提交，我们可以这样绘制它们：
A <-B <-C <--master
名称 master 指向最后一次提交，C。提交 C 本身指向较早的提交 B，后者指向 very-first 提交 A。 （因为 A 是 very-first 提交，它只是不指向任何地方，这就是 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
标签名称没有移动，也不应该移动。 （您可以手动“移动”一个，删除它并创建另一个同名的，或者使用其中一个强制选项，但通常您不应该这样做。）
Is it possible to check out this tagged commit if the release branch was deleted ...
当然可以。分支名称、标记名称和其他名称用于定位一个特定的提交。您可以使用该名称直接转到该提交。只要名称本身继续存在，提交本身就会保留在 Git 存储库中。
找到一些提交——通常是通过名称——Git 可以使用嵌入在每个提交中的内部箭头在历史中向后移动。这意味着如果提交 D 有一个名称，如上图所示，Git 可以使用 D 找到 C，它可以使用它找到 [=21] =]，它可以用来查找 A。因此，这四个提交将保留在此存储库中，因为 D 是 find-able.
注意名称master定位到commitF，这意味着commitF被保留。 Commit F 定位到commit E，commit E定位到D，以此类推；所以这些提交也将被保留。因此有两个名字表示必须保留D-and-earlier。删除其中任何一个名称都会将 D-retaining-names 的数量减少到 1，但仍必须保留 D。但是，如果我们删除的名称是 master，则不再需要保留提交 F。如果提交 F 被抛出，这意味着提交 E 也不再是 find-able，并且提交 E 也可以被抛出。
如果我们添加另一个名称来查找 F，从某种意义上说，删除名称 master 就变得安全了。删除名称 master 将在效果，“忘记” master 中的 last 提交此时是提交 F，但提交 F 将是 find-able 通过一些 other 名称，因此不会被丢弃。
请注意，任何合并提交都有两个（或更多1）个箭头。如果该合并提交是 find-able，则来自它的箭头会保留沿这些路径的所有较早提交。因此，一旦您将一些 branch-tip 提交（由某个分支名称标识）合并到您打算保留其名称的其他分支中，删除合并分支的名称是安全的：您将无法找到该提示直接 提交，但您可以通过找到将其作为其中之一的 merge 提交 来 间接 找到它它额外的父提交哈希ID。
1Git 称为这种合并，其中有两条以上的“腿”，章鱼合并。这可能就是为什么 GitHub 使用 octocat 作为他们的标志。
答案正确，但有点复杂。这是一个简短的回答：
If the release branch contains Tags and if the release branch is merged into the master after the last released version of release/1.x.y, are the tags also merged?
标签与分支关系不大。它们只指向一个特定的提交——提交在哪个分支并不重要。
所以是的，标签在合并后仍然可用。
And for long term support my question is:
Let's assume somebody wants to check out the state of tag 1.1.1 in 10 years. Is it possible to check out this tagged commit if the release branch was deleted but was merged into the master and we have the master ?
是的。
假设我们正在使用 git 和拉取请求进行开发，并且我们有：
- 一个主分支
- 一个release/1..分支 对于每个修补程序或功能，还有一个分支，在接受拉取请求后合并到起始分支中。
所以我的问题是：
如果release分支包含Tags，如果release分支在release/1.x.y的最后一个发布版本之后合并到master中，那么tags是否也合并了？
对于长期支持，我的问题是：
假设有人想查看 10 年后标签 1.1.1 的状态。 如果 release 分支被删除但合并到 master 并且我们有 master ，是否可以检查这个标记的提交？
谢谢
1.) If the release branch contains Tags and if the release branch is merged into the master after the last released version of release/1.x.y, are the tags also merged?
标签未合并，提交（标记或未标记）合并。
2.) And for long term support my question is: Lets assume somebody wants to check out the state of tag 1.1.1 in 10 years. Is it possible to check out this tagged commit if the release branch was deleted but was merged into the master and we have the master ?
是的，这不仅是可能的，而且是标签的真正目的。标签是对特定提交的永久引用，因此这些提交以后仍可访问以供检查，即使它们没有合并到任何东西中。
如果你只是将开发分支合并到 Master，你不会丢失标签。标签和分支之间的区别在于标签是特定提交的标记（标签不会随着下一次提交而移动。反过来，分支会随着每次提交而移动）。因此，如果您进行合并操作，并使用标签推送提交，您可以返回到带有标签的 tags/commits。
您只需要记住将标签推送到远程存储库即可。 Example merge branches with tags
您主题行中问题的字面答案——git 标签合并了吗？——是“否”，但这不是一个有趣的答案，因为两者都不是是 分支名称 。合并，在 Git 中完成 提交 .
您张贴的图表还不错，但其中有一些东西具有误导性。这里有一些关于它的注释：
里面的箭头指向前方。 Git 不向前工作； Git 向后工作。通常这无关紧要，但就发现 提交而言，这很重要。
圆圈代表提交。一切都很好。
一些提交是合并提交，一些提交是普通提交。在这种情况下，所有紫色
feature/*提交都是普通的，单个bugfix/bug-1红色提交也是如此。大多数黄色和绿色提交都是合并提交。由于图中的箭头方向错了——它们向前而不是 Git 的 backwards-ness——你可以分辨出哪些提交是合并提交，因为它们有多个箭头来到他们身边。如果箭头被正确绘制，即向后，合并提交将是任何带有两个或更多箭头的提交 out。
分支名称和标签名称仅标识一个 提交。该图在这里具有很大的误导性，因为它将名称
master和release/1.0.0放在了左侧。如果这些是分支名称，它们确实应该在右边，指向该分支中的最后一次提交。Git 利用了每次提交的箭头——也就是说， 将 来自每次提交的箭头，如果箭头正确绘制 - 工作 向后 。因此 分支名称 总是 标识分支中的 last 提交。这意味着该名称指向链中的最后一次提交。
标签名称，如分支名称，直接指向一个提交。标记名称和分支名称之间的主要区别包括 分支名称随时间移动 ，因此当您添加新提交时，名称继续指向 最后 提交。因此，如果我们有一个只有三个提交的小型存储库，并且我们使用大写字母（而不是圆圈）来代表这些提交，我们可以这样绘制它们：
A <-B <-C <--master
名称 master 指向最后一次提交，C。提交 C 本身指向较早的提交 B，后者指向 very-first 提交 A。 （因为 A 是 very-first 提交，它只是不指向任何地方，这就是 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
标签名称没有移动，也不应该移动。 （您可以手动“移动”一个，删除它并创建另一个同名的，或者使用其中一个强制选项，但通常您不应该这样做。）
Is it possible to check out this tagged commit if the release branch was deleted ...
当然可以。分支名称、标记名称和其他名称用于定位一个特定的提交。您可以使用该名称直接转到该提交。只要名称本身继续存在，提交本身就会保留在 Git 存储库中。
找到一些提交——通常是通过名称——Git 可以使用嵌入在每个提交中的内部箭头在历史中向后移动。这意味着如果提交 D 有一个名称，如上图所示，Git 可以使用 D 找到 C，它可以使用它找到 [=21] =]，它可以用来查找 A。因此，这四个提交将保留在此存储库中，因为 D 是 find-able.
注意名称master定位到commitF，这意味着commitF被保留。 Commit F 定位到commit E，commit E定位到D，以此类推；所以这些提交也将被保留。因此有两个名字表示必须保留D-and-earlier。删除其中任何一个名称都会将 D-retaining-names 的数量减少到 1，但仍必须保留 D。但是，如果我们删除的名称是 master，则不再需要保留提交 F。如果提交 F 被抛出，这意味着提交 E 也不再是 find-able，并且提交 E 也可以被抛出。
如果我们添加另一个名称来查找 F，从某种意义上说，删除名称 master 就变得安全了。删除名称 master 将在效果，“忘记” master 中的 last 提交此时是提交 F，但提交 F 将是 find-able 通过一些 other 名称，因此不会被丢弃。
请注意，任何合并提交都有两个（或更多1）个箭头。如果该合并提交是 find-able，则来自它的箭头会保留沿这些路径的所有较早提交。因此，一旦您将一些 branch-tip 提交（由某个分支名称标识）合并到您打算保留其名称的其他分支中，删除合并分支的名称是安全的：您将无法找到该提示直接 提交，但您可以通过找到将其作为其中之一的 merge 提交 来 间接 找到它它额外的父提交哈希ID。
1Git 称为这种合并，其中有两条以上的“腿”，章鱼合并。这可能就是为什么 GitHub 使用 octocat 作为他们的标志。
答案正确，但有点复杂。这是一个简短的回答：
If the release branch contains Tags and if the release branch is merged into the master after the last released version of release/1.x.y, are the tags also merged?
标签与分支关系不大。它们只指向一个特定的提交——提交在哪个分支并不重要。
所以是的，标签在合并后仍然可用。
And for long term support my question is:
Let's assume somebody wants to check out the state of tag 1.1.1 in 10 years. Is it possible to check out this tagged commit if the release branch was deleted but was merged into the master and we have the master ?
是的。