在持续集成环境中处理版本控制

Question

在一个有开发分支和发布分支的持续集成环境中，如何处理版本控制？我使用git，所以没有增量仓库版本可用。似乎会出现重叠版本，例如dev分支上的1.1.0和发布分支上的1.1.0。您只需在文本中添加“dev”或“release”吗？

此外，当您创建发布分支时，是否立即将开发分支递增到下一个“拟议”的发布号？您可能还不知道下一个发布号，但如果不递增，则1.1.0 dev包含未包含在1.1.0 release中的新工作。

因此，我的主要问题是这两个分支之间版本控制序列的关系是什么？

请注意，我不是在问如何决定使用哪些版本号。我之前试过询问，但一直收到“增加主要版本以进行破坏性更改”等评论。

- JC.

Answer 1

我不对dev分支进行版本控制。dev线是主干，我会定期从dev分支创建新的发布文件夹。因此，发布分支中充满了基本上是dev线快照的文件夹。

例如，在根目录下，我有/dev、/releases/0.1、/releases/0.2、/releases/1.0等。

我不确定这是否真正回答了你的问题。

- David

---

我的经验是这是最好的方式。 - NotMe

Answer 2

我建议为您的CI环境设置一个最终活动来制作标签。我相信git命令看起来像这样：git tag -a name。

我们使用Major.Minor.Release.BuildNumber，虽然有些地方使用Major.Minor.Release.CheckinNumber。

因此，如果您想使用它，那么我会对您的开发分支进行版本控制，否则只需对发布分支进行版本控制。

- Lucas B

---

那么开发分支和发布分支的构建版本号是没有关联的吗？ - JC.

主要.次要.发布.构建编号它们之间没有关联 主要.次要.发布.检入编号它们之间有关联且耦合 - Lucas B

Answer 3

如果您只有一个开发分支，将其作为主干并每次仅想稳定发布时分支出一个发布分支会更有效。如果您有多个功能项目，则可以为每个项目设置一个分支，并在这些分支上设置CI。完成后，您逐个将它们合并到主干中，一旦所有内容都合并完成，您就会回到第一种情况，即再次从主干分支出一个发布分支。

无论如何，在发布之间不要保持开发分支。您希望结束它并为下一个版本开始一个新的开发分支。这样，如果某些功能需要更长时间，它们的某些特性可以在几个版本中分支出来。但是，您也不希望在开发分支上出现太多混乱。

您可以在分支出发布分支后甚至在此之前为下一个版本分支出开发分支，但是一般而言，一旦您稳定发布，将发布分支中的更改合并到主干中，然后再将其合并到开发分支中是个好主意。如果您等待发布后再进行分支，您可以避免一些合并，但是会减缓开发速度。

- Jiri Klouda