从 git 标签创建分支是一个很好的做法吗？

Question

我已经开始与一个新的开发团队合作，他们有一个我在 git-book 中找不到关于分支管理的实践：

他们使用单个分支来集中更改并为每个版本关闭一个标签。总的来说这里没有新闻，但是：

• 一旦我们需要修补程序，他们就会从标签创建一个修复分支；
• 进行更改，然后向后合并该主分支；

我的疑问是：

1. 根据我的理解，

   git log

   甚至

   gitk

   显示靠近提交的标签，只是为了关联该标签给出的提交ID是它的起源：

2. 但是，根据定义，标签是快照，因此它们是分离的：

这样做的真正优势/风险是什么？从来没有看到一个团队像这样工作，并且怀疑我们可能会陷入严重的陷阱。

有什么困难吗？预先感谢您。

1. 尝试从标签创建分支 - 效果很好；
2. 将从标签创建的合并分支返回到另一个分支 - 也可以正常工作；
3. 从源自标签的分支进行变基过程和另一个递归操作 - 也可以；
4. 似乎即使是分离的，一旦我们从标签创建分支，一切都会正常工作。

它们可能显示在 git 树中，但在概念标签中不属于“正式的 git 树”，这让我很烦恼，并且与我在 git-book 中学习的内容背道而驰...

我希望对这个问题有一个明确的答案，因为这里的人已经习惯了，但是很明显最后一个标签应该等于 master 的 HEAD，所以 PR 修复应该从 master 创建。

2 月 10 日更新：

在“分离的 HEAD”状态下，如果您进行更改然后创建提交，标记将保持不变，但您的新提交将不属于任何分支并且将无法访问，除非通过确切的提交哈希。因此，如果您需要进行更改——例如，假设您正在修复旧版本上的错误——您通常会想要创建一个分支。 如果您执行此操作并进行提交，您的 version2 分支将与 v2.0.0 标记略有不同，因为它将随着您的新更改而前进，因此请务必小心。 参考。

Answer 1

您报告的行为是正常的，也是最佳做法。

考虑一下我们在这里想要做什么。我们有一个代表发布状态的提交，它位于空间中，除了标签之外没有任何东西指向它（并使其保持活动状态）：

A -- B -- C (main)
      \
       X 
       ^ [tag: release1.1.1]

我们现在在版本中发现了一个错误，我们需要对其进行修复。因此，我们需要执行两项任务：

(1) 修复版本本身的错误并提交该修复。

(2) 将修复合并回

main

。

问题就出在“承诺”这个词上。该提交将去往架构中的哪个位置？您可以从签出（切换到）标签开始，然后根据需要多次编辑和提交：

A -- B -- C (main)
      \
       X -- Y -- Z
       ^ [tag: release1.1.1]

但问题是我们现在没有办法refer到Z，它包含了这里的最终修复。我们现在当然可以标记 Z，而且我们很可能会这样做；但我们必须通过它的 SHA 来“引用”它。更重要的是，一直以来，当我们致力于制作 Y 和 Z 时，我们一直在“分离头”模式下工作，这种模式使用起来非常笨拙，尤其是在多人合作修复此问题的情况下。 相反，让生活变得简单：首先在标记点开始一个分支。这样，当我们处理 Y 和 Z 时，我们就在

在分支上

工作，这始终是使用 Git 的最佳方式：

A -- B -- C (main)
      \
       X -- Y -- Z (hotfix)
       ^ [tag: release1.1.1]

现在我们只需用新的版本号标记

hotfix

，然后发布它；然后切换到

main

并合并

hotfix

。我们现在可以删除

hotfix

；它已经完成了它的工作。如果其中任何一个让您感到困惑，并且没有应有的明显和直观，也许问题在于您只是不知道分支是什么。它不是链接提交的连续体；它只是一个字符串、一个引用、一个标签、“只是一次提交”的临时名称。 git 中的分支非常轻量，它们应该快速地来来去去，就像虚拟粒子一样突然出现和消失。分支有三个用途：

它为提交提供了方便的标签。

它会在你工作时保持该提交（及其及时返回的父母链）的活力。

• 当您在分支为 HEAD 时添加并提交时，分支名称会自动移动以指向该新提交。
所以在我看来，给你的教训可能是
• 创建更多分支！
你应该灵活且灵活地创建分支；每当您有工作要做或有想法要尝试时，就制作一个。它们不会花费您（和 Git）任何成本，而且随着您的前进，它们会让生活变得更加简单。