假设我有一些最后发布的版本是 1.1 的软件。从那里开始的发展继续在两个轨道上：
masterapril_fools分支。我的计划是将临时代码标记为v1.2并发布它，但永远不要将它合并到 master。这是因为如果我合并它：
版本 1.3 将根据master时间到来的最新提交进行标记和发布。
这似乎是最干净的解决方案，但我有点犹豫。我是否应该担心在 1.1 和 1.3 版本中没有标记为 1.2 的介入提交的提交世系？这是否会导致后来查看提交历史的开发人员感到困惑？
分支相互转移的时间越长，合并就越糟糕，如果最终你以后会被迫这样做的话。
万一当前的主线稍后会被丢弃，在它上面所做的所有工作都将付诸东流。这个决定花费的时间越长，情况就会越糟。又来气了。
由于它是一个永远不会被合并回来的分叉，所以不要用1.2.
给它起一个有用的名字，这会让你明白那里发生了什么。
即使你不知道发生了什么变化。让它防白痴。你现在和半年后的你，从知识上来说，不是同一个人。
你的计划对我来说听起来最好。如果我正在处理存储库并看到 v1.2 被跳过，这可能会让我想知道为什么，我可能会记下稍后查找它，但这并不会真正阻止我当时做任何工作. 我以前使用过带有奇怪版本编号的软件，所以我可能只是假设它过去是一些内部小混乱。
对于好奇的开发人员，您可以记录“v1.2 在哪里？” 在您的项目文档中 - 在您的项目 wiki 或docs文件夹或其他任何内容中。尽管如果您唯一的文档是自述文件，那么添加它可能根本不够重要。
简短的回答：没有。
标签是对 DAG 中提交的引用，您并不真正关心该图的历史连续性。
您只关心获取标签引用的确切内容。
如果标记为 1.2 的分支和标记为 1.3 的 master 之间没有合并，则强调开发过程中的明显中断（因为重构）。
只要尊重版本号策略的语义（1.2 -> 1.3 完全 API 兼容性），您就可以开始了。