版本是在开发分支中还是在主分支中呢？

Question

我在主分支(默认分支)中发布了API 1.0.0。从那时起，我分别分支到分支api2/foo和api2/bar，这两个分支都包含了向后不兼容的更改。

API版本在源代码中声明。应该在api2 2/*分支中还是在主分支中将版本提高到2.0.0？

如果我在主分支中插入版本，那么api2 2/*分支上的源代码中的版本将不会被更新。如果我要为分支发布开发构建，那么当项目声明为API 1时，可能会使用API 2中的内容。因此，我必须将主分支中的提交合并到与版本发生碰撞的主分支中，但我将在主分支中进行其他更改，而且我还不希望它发生。

另一方面，如果我在dev分支中插入版本，将有两个版本提交，因此当它们都合并到主分支中时，可能会发生冲突。

在这两种选择之间有什么好的解决方案？

Answer 1

在您的CI服务器上生成发行版时，对代码进行版本化。

通常情况下，这将是在签入开发，掌握，如果您没有开发分支。

如果您对特性分支进行了版本化，您将陷入麻烦，因为没有明确的定义哪个是“最新”版本。

由于缺少开发分支，而且这两个更改都不兼容，因此必须：

• 将foo合并到主版中，构建v2
• 将主程序合并成条形，修复不兼容
• 将条形合并成主程序，生成v3

Answer 2

潜在的问题是:什么是好的提交大小？

我的建议是:提交应该包含单个但完全的更改。

“单行”是指尽可能少的换行量。

“完成”意味着项目编译并成功地运行所有自动化测试。

从这个意义上说，“版本碰撞”是如此单一但完全的改变。

如果“版本凸点”在单独的提交中，那么在合并之前您可以简单地删除(跳过) git rebase -i提交的提交。

Answer 3

在我看来，在两个分支中分别更新到2.0.0是不明智的，因为这意味着它们都代表版本2.0.0。但这显然是一个矛盾，因为它们互不相容。使用相同版本号的两个不兼容的构建首先会破坏版本控制的全部目的！

您应该将两者合并到一个发布分支中，或者将foo合并到bar中(反之亦然)，然后将版本提高到2.0.0。然后你可以把它合并回主人。