两个功能分支齐头并进时版本号怎么管理？

[ljpCN]

比如有两个分支 feature a 和 feature b，两个功能互相独立。

当前版本号是 1.0.0，feature a 此时开发完成一部分后，发布了一个测试版本供测试人员测试，版本号是 1.0.1 。

然后 feature b 此时也提测，于是发布一个版本 1.0.2，因为他们知道 feature a 已经提测了，于是他们在发布之前 rebase 了 feature a 的代码，所以这个版本号没有问题。

但接下来 feature a 修复了一些 bug 后直接发布了 1.0.3 交给测试人员测试，因为是回归测试担心引入新的 bug，他们没有去 rebase feature b 。这时的 1.0.3 这个版本号就有些问题，它比 1.0.2 大，却不具备 1.0.2 已经实现的一些功能。

老哥们有这方面的实践经验吗？

[msg7086]

不进开发分支的时候版本号没意义啊，本来就不是递增的。可以考虑尾巴上加 tag ？

[heliang]

为什么要改变版本号呢，build number 不能用吗？同一个 feather 不应该是同一个版本号吗？修复 bug 之类的只需要修改 build number 就好了呀！

[swulling]

你这个时典型的分支开发分支发布模型，传统的三位版本号不适用这个模型。

要么你改成分支开发主干发布，即只允许 merge 到主干分支才能发版
要么就是版本号进行修改，保留分支信息。推荐用 https://semver.org/lang/zh-CN/ 规范，比如你这个就可以发布为
1.0.0-branch_a-xxxxx
1.0.0-branch_b-xxxxx

分别递增 xxxxx，甚至可以用时间来做 xxxxx，等最终 merge 到主干后，再发布 1.0.1 版本

[gayluote]

先创建两个远程分支 featureA 和 featureB，和追踪分支 A1 对应 featureA，B1 追踪 featureA 。开发人员在 A1 和 B1 上开发，A1/B1 可以随时提交合并到 featureA/featureB 。但是测试人员只测试 featureA 和 featureB2 个分支。确认 featureA 测试完成后再合并 master 。featureB 注意回合代码就行了

[gayluote]

@gayluote 笔误，B1 追踪 featureB

[ljpCN]

@msg7086
@heliang
@swulling
@gayluote 的确，现在这个开发分支也会影响版本号的确不太好。主要是因为部署到测试环境前打包代码系统需要填写一个版本号。现在看来直接用分支代码部署，不走打包环节比较好。

[SmiteChow]

测试只能在主干上进行，因为只有主干会部署到生产环境。

[ljpCN]

@SmiteChow 目前我们的主干只允许部署到生产环境前修改。测试完成前不允许 merge 到 master