如何在具有开发分支和发布分支的持续集成环境中处理版本控制？我使用的是git，所以没有使用增量版本库。似乎会有重叠的版本，如dev分支上的1.1.0和发行分支上的1.1.0。你只是附加文字“dev”或“release”？在持续集成环境中处理版本控制
此外，当您创建发布分支时，是否立即将开发分支增加到下一个“建议”版本号？你可能还不知道下一个版本号，但是如果你不增加它，那么你的1.1.0版本包含了1.1.0版本以外的新工作。
所以我的主要问题是这两个分支之间版本控制序列中的关系是什么？
请记住，我不问任何关于如何决定使用哪个版本号的问题。我试着问过这个问题，并不断收到评论，如“增加主要突破变化”等。
我没有版本的开发分支。 devline是主干，我定期从开发分支到新版本文件夹。因此发行版分支充满了基本上是设备快照的文件夹。
IE，下根我的/ dev，/releases/0.1，/releases/0.2，/releases/1.0等
我不知道这是否真的回答你的问题。
我会建议为您的CI环境设置一个最终活动来制作标签。我相信git的命令如下：git的标签-a命名
我们使用Major.Minor.Release.BuildNumber
虽然有些地方使用Major.Minor.Release.CheckinNumber
所以，如果你想要使用它，那么我将版本的开发分支，否则只是版本分支。
因此，开发分支与发布分支的内部版本号无关？ – 2010-04-07 20:24:02
Major.Minor.Release.BuildNumber它们是无关的 Major.Minor.Release.CheckinNumber它们是相关的并且耦合的 – 2010-04-09 15:18:54
如果您只有一个开发分支，那么每次您只想稳定以便发布时，使其成为发布分支的主干和分支会更有效。如果您有多个功能项目，那么您可以为每个功能项目设置CI分支。一旦完成，您将它们逐一合并到主干，并且一旦所有合并完成，您就会到达第一个场景，在此您再次从主干分支出发布分支。
在任何情况下，您都不会让开发分支在发布之间进行。你想结束它并为下一个版本的开发启动一个新的开发。这样，如果某些功能需要更长时间，则可以在多个版本中分出一些功能。但是，您的开发分支也不会太多。
只要分支发布分支，或者甚至在选择分支之前，您都可以为下一个版本分支开发分支，但一旦您稳定以便发布，通常是个好主意，将发布分支中的更改合并到主干并从那里进入开发部门，如果你这样做。如果您在发布后等待分支，那么您可以避免少量合并，但会减慢开发速度。
我的经验是，这是最好的方法。 – NotMe 2010-09-22 21:38:04