如何在有开发分支和发布分支的持续集成环境中处理版本控制？我正在使用git，因此没有使用增量存储库版本。似乎会有重叠版本，例如dev分支上的1.1.0和发布分支上的1.1.0。你只是附加文本“dev”或“release”吗？
此外，当您创建发布分支时，您是否立即将开发分支增加到下一个“建议”版本号？您可能还不知道下一个版本号，但如果您不增加它，那么您的1.1.0 dev包含1.1.0版本中未包含的新工作。
所以我的主要问题是这两个分支之间的版本控制序列之间的关系是什么？
请记住，我不会询问如何决定使用哪个版本号。我之前尝试过这样做，并不断得到像“增加主要用于破坏变化”等评论。
答案 0 :(得分：3)
我没有对dev分支进行版本控制。 devline是trunk，我定期从dev分支到一个新的release文件夹。因此，发布分支中充满了文件夹，这些文件夹基本上是devline的快照。
IE，在root下我有/ dev，/ release0 / 0.1，/ release0 / 2，/ release1 / 1等。
我不确定这是否真的能回答你的问题。
答案 1 :(得分：1)
我建议您为CI环境设置最终活动以制作代码。我相信git命令看起来像这样：git tag -a name
我们使用Major.Minor.Release.BuildNumber
虽然有些地方使用Major.Minor.Release.CheckinNumber
所以，如果你想使用它，那么我会对你的dev分支进行版本控制，否则只需对发布分支进行版本化。
答案 2 :(得分：0)
如果你只有一个开发分支，每次你想要稳定发布时，让它成为发布分支的主干和分支会更有效。如果您有多个要素项目，则可以为每个要素项目设置一个分支，并在其上设置CI。完成后，将它们逐个合并到主干，一旦合并完毕，您将进入第一个场景，再次从主干分支释放分支。
在任何情况下，您都不会让开发分支在版本之间保持不变。您希望结束它并为下一个版本开始一个新的开发。这样一些功能可以在几个版本中分支，如果它们需要更长时间。但是你的开发分支也没有太多的混乱。
一旦分支发布分支，甚至在您选择之前，您就可以为下一个版本分支开发分支，但是一旦稳定发布，将更改从发布分支合并到主干，通常是个好主意。从那里进入开发分支，如果你这样做。如果你在发布后等待分支，你可以避免在那里进行少量合并，但是你会减慢开发速度。