在 tag/release 之后或 tag/release 完成时，您会在什么确切时刻更改代码版本？
In what exact moment do you change your code version, just after a tag/release or when the tag/release is finished?
假设您有一堆代码，并且假设您有第一个工作版本。这是 1.0 版。您转到 git 存储库并标记版本。然后就在那一刻，你有了第一个标签或版本。然后，您的代码版本号为 1.0，存储库标签号为 1.0。
我的问题是，您到底什么时候将代码中的版本号更改为 1.1 版（假设我们不关心 1.0.1）：
A) tag 1.0 做完后你是不是马上改？因此，从这一刻起，您的所有代码都属于 1.1 版。这个版本"ends"当你新建一个tag 1.1，就是稳定版1.1，在代码里改成1.2版。
B) 在你做了几次代码更改并发布了你的第二个标签（标签 1.1）之后，你会更改它吗？在这种情况下，您拥有稳定代码的标记版本 1.0，并且您正在对代码进行改进。您所做的所有新更改都属于 1.0 版。然后当您完成更改时，将代码编号更改为 1.1，将标签编号更改为 1.1
书呆子问题正确 ;-)
这有点主观，但我强烈建议 A. 在发布时分支并开始在新分支中工作。
这是因为您的用户随后会与您在 v1 中离开的地方保持同步。如果您为工作的 v1.1 分支引入了许多功能，并且可能有一些设计更改强烈偏离 v1，您总是可以通过更新到 v1 分支回到用户看到的内容。
以这种基于发布的方式进行分支很有用，因为 "checkpoints" 基于用户实际拥有的内容，而不是基于您打算交付的内容。这样，当用户报告某事时，您可以轻松了解他们实际使用的代码版本，并快速点击它。
这也为轻松 "service patches" 留出了喘息的空间，例如 v1.01。我知道你写道你不关心这个，但是如果你的用户在 v1 中报告了一个你已经在 v1.1 中解决的问题，或者 v1.1 的设计已经改变，使其不再存在有效，但你想在两者之间偷偷打一些补丁，你可以更新到你的 v1 分支，做一个小调整，然后发布 v1.01 服务补丁之类的东西。那里有更多的回旋余地。
作为一个假设，假设用户报告 v1 中的一个故障。您不能在最新的开发分支中重现它。现在，您无法在当前变更集中重现它这一事实是否意味着它已修复，或者您根本无法重现它？最简单的确定方法是能够快速切换并使用您发布给用户的相同版本。这就是在发布时分支和冻结分支的有用之处。
当然，如果您只是以一种您知道哪个是哪个的方式评论您的变更集，那么您当然可以做到这一点而根本没有分支或标记。但是在发布的上下文中 tagging/branching 没有什么意义。如果您将其作为一种组织方式和一种将变更集隔离到一个地方的方式来进行，我建议您以一种使这些分支与用户实际拥有的内容保持同步的方式来进行。
假设您有一堆代码，并且假设您有第一个工作版本。这是 1.0 版。您转到 git 存储库并标记版本。然后就在那一刻，你有了第一个标签或版本。然后，您的代码版本号为 1.0，存储库标签号为 1.0。
我的问题是，您到底什么时候将代码中的版本号更改为 1.1 版（假设我们不关心 1.0.1）：
A) tag 1.0 做完后你是不是马上改？因此，从这一刻起，您的所有代码都属于 1.1 版。这个版本"ends"当你新建一个tag 1.1，就是稳定版1.1，在代码里改成1.2版。
B) 在你做了几次代码更改并发布了你的第二个标签（标签 1.1）之后，你会更改它吗？在这种情况下，您拥有稳定代码的标记版本 1.0，并且您正在对代码进行改进。您所做的所有新更改都属于 1.0 版。然后当您完成更改时，将代码编号更改为 1.1，将标签编号更改为 1.1
书呆子问题正确 ;-)
这有点主观，但我强烈建议 A. 在发布时分支并开始在新分支中工作。
这是因为您的用户随后会与您在 v1 中离开的地方保持同步。如果您为工作的 v1.1 分支引入了许多功能，并且可能有一些设计更改强烈偏离 v1，您总是可以通过更新到 v1 分支回到用户看到的内容。
以这种基于发布的方式进行分支很有用，因为 "checkpoints" 基于用户实际拥有的内容，而不是基于您打算交付的内容。这样，当用户报告某事时，您可以轻松了解他们实际使用的代码版本，并快速点击它。
这也为轻松 "service patches" 留出了喘息的空间，例如 v1.01。我知道你写道你不关心这个，但是如果你的用户在 v1 中报告了一个你已经在 v1.1 中解决的问题，或者 v1.1 的设计已经改变，使其不再存在有效，但你想在两者之间偷偷打一些补丁，你可以更新到你的 v1 分支，做一个小调整，然后发布 v1.01 服务补丁之类的东西。那里有更多的回旋余地。
作为一个假设，假设用户报告 v1 中的一个故障。您不能在最新的开发分支中重现它。现在，您无法在当前变更集中重现它这一事实是否意味着它已修复，或者您根本无法重现它？最简单的确定方法是能够快速切换并使用您发布给用户的相同版本。这就是在发布时分支和冻结分支的有用之处。
当然，如果您只是以一种您知道哪个是哪个的方式评论您的变更集，那么您当然可以做到这一点而根本没有分支或标记。但是在发布的上下文中 tagging/branching 没有什么意义。如果您将其作为一种组织方式和一种将变更集隔离到一个地方的方式来进行，我建议您以一种使这些分支与用户实际拥有的内容保持同步的方式来进行。