在有开发分支和发布分支的持续集成环境中，您如何处理版本控制？我正在使用 git，因此没有可使用的递增存储库版本。似乎会有重叠的版本，例如 dev 分支上的 1.1.0 和 release 分支上的 1.1.0。你只是附加文本“dev”还是“release”？
另外，当你创建一个发布分支时，你是否立即将开发分支增加到下一个“建议的”发布号？您可能还不知道下一个版本号，但如果您不增加它，那么您将拥有 1.1.0 开发版，其中包含 1.1.0 版中未包含的新工作。
所以我的主要问题是这两个分支之间的版本控制顺序是什么关系？
请记住，我不是在询问如何决定使用什么版本号。我之前尝试过问这个问题，并不断得到诸如“用于重大更改的增量”等的 cmets。
【问题讨论】：
标签： continuous-integration versioning
我不对 dev 分支进行版本控制。 devline 是主干，我会定期从 dev 分支到新的发布文件夹。所以发布分支充满了文件夹，这些文件夹基本上是开发线的快照。
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
所以，如果你想使用它，那么我会对你的 dev 分支进行版本控制，否则只需对发布分支进行版本控制。
【讨论】：
如果你只有一个开发分支，那么每次你只想稳定发布时，让它成为主干并分支出一个发布分支会更有效。如果您有多个功能项目，则可以为每个项目创建一个分支，并在这些项目上设置 CI。完成后，将它们一个接一个地合并到主干中，一旦全部合并，就进入第一个场景，再次从主干分支发布分支。
在任何情况下，您都不会在发布之间保持开发分支。您想结束它并为下一个版本开始一个新的开发。这样，如果需要更长的时间，某些功能可以在多个版本中分支出来。但你的开发分支也不会太乱。
您可以在分支发布分支后立即为下一个版本分支开发分支，如果您愿意，甚至可以在此之前分支，但是一旦您稳定发布，将发布分支中的更改合并到主干和如果你这样做，从那里进入开发分支。如果您在发布后等待分支，您可以避免在那里进行少量合并，但会减慢开发速度。
【讨论】：