让我们说你有一堆代码，让我们假设你有一个第一个工作版本。这是1.0版。你去你的git仓库并标记版本。然后在那个确切的时刻，你有第一个标签或版本。然后，您的代码版本号为1.0，而您的存储库标签号为1.0。
我的问题是，您何时将代码中的版本号更改为1.1版（让我们假设我们不关心1.0.1）：
A）标签1.0完成后你马上改变它吗？因此，此时所有代码都属于1.1版。这个版本＆＃34;结束＆＃34;当你创建一个新标签1.1，这是稳定版本1.1并在代码中更改为版本1.2。
B）在完成多个代码更改并发布第二个标记（标记1.1）后，您是否更改了它？在这种情况下，您拥有稳定代码的1.0版标记，并且您正在对代码进行改进。您所做的所有新更改都属于1.0版。然后，当您完成更改后，将代码编号更改为1.1，将标记编号更改为1.1
书呆子问题; - ）
答案 0 :(得分：0)
这有点主观，但我强烈建议A.在发布时分支出来并开始在新分支工作。
这是因为您的用户与您在v1中停下的位置保持同步。如果您为工作的v1.1分支引入了许多功能，并且可能还有一些设计更改，这些功能从v1强烈分支出来，您可以通过更新到v1分支来回到用户看到的内容。
基于发布的这种分支方式非常有用，因为＆＃34;检查点＆＃34;基于用户实际拥有的内容，而不是基于您打算提供的内容。这样，当用户报告某些内容时，您可以轻松地知道他们实际使用的代码版本并快速浏览它。
这也留下了一些喘息的空间来做容易的服务补丁＆＃34;，就像v1.01一样。我知道您写道，您并不关心这一点，但是如果您的用户在v1中报告了您已经在v1.1中解决过的问题，或者v1.1设计已经改变了让它不再有效，但是你想要在它们之间偷看一些补丁，你可以更新到你的v1分支，做一个小调整，并发布一个v1.01服务补丁类的东西。对于那种事情，那里有更多的摆动空间。
作为一个假设，假设用户在v1中报告了一个小故障。您无法在最新的开发分支中重现它。现在您无法在当前的变更集中重现它意味着它已经修复，或者您根本无法重现它吗？最简单的方法是能够快速切换并使用您发布给用户的相同版本。在释放时分支和冻结分支的情况很有用。
当然，如果您只是以某种方式评论您的更改集，那么您可以在不进行分支或标记的情况下执行此操作，以便您知道哪个是哪个。但是，在发布的上下文中，标记/分支没有什么意义。如果你把它作为一种组织手段和一种将变更集隔离到一个地方的方式，我建议这样做，以使这些分支与用户实际拥有的内容保持同步。