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

2018-06-15 23:31:09

如何在具有开发分支和发布分支的持续集成环境中处理版本控制？我使用的是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 tag -a name

我们使用Major.Minor.Release.BuildNumber

尽管有些地方使用Major.Minor.Release.CheckinNumber

所以，如果你想使用它，那么我会为你的开发分支版本，否则版本分支版本。

如果你只有一个开发分支，那么每当你想稳定发布时，将它作为主干和分支发布分支会更有效。如果您有多个功能项目，那么您可以为每个功能项目设置CI分支。一旦完成，您将它们逐一合并到主干，并且一旦所有合并完成，您就会到达第一个场景，在此您再次从主干分支出发布分支。

在任何情况下，您都不会让开发分支在发布之间进行。你想结束它并为下一个版本的开发启动一个新的开发。这样，如果某些功能需要更长时间，则可以在多个版本中分出一些功能。但是，您的开发分支也不会太多。

一旦分支发布分支，甚至在选择分支之前，您就可以为下一个版本分支开发分支，但是一旦您稳定发布，通常是个好主意，将发布分支中的更改合并到主干中，开发分支如果你这样做。如果您在发布后等待分支，那么您可以避免少量合并，但会减慢开发速度。

链接地址: http://www.djcxy.com/p/45283.html