这是一个创建于 1420 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如有两个分支 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 已经实现的一些功能。
老哥们有这方面的实践经验吗？
 |
1
msg7086 2021-01-06 10:59:08 +08:00
不进开发分支的时候版本号没意义啊，本来就不是递增的。可以考虑尾巴上加 tag ？
|
 |
2
heliang 2021-01-06 11:05:15 +08:00
为什么要改变版本号呢，build number 不能用吗？同一个 feather 不应该是同一个版本号吗？修复 bug 之类的只需要修改 build number 就好了呀！
|
 |
3
swulling 2021-01-06 11:06:22 +08:00
你这个时典型的分支开发分支发布模型，传统的三位版本号不适用这个模型。
要么你改成分支开发主干发布，即只允许 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 版本 |
 |
4
gayluote 2021-01-06 17:05:14 +08:00
先创建两个远程分支 featureA 和 featureB，和追踪分支 A1 对应 featureA，B1 追踪 featureA 。开发人员在 A1 和 B1 上开发，A1/B1 可以随时提交合并到 featureA/featureB 。但是测试人员只测试 featureA 和 featureB2 个分支。确认 featureA 测试完成后再合并 master 。featureB 注意回合代码就行了
|
 |
6
ljpCN OP |
 |
7
SmiteChow 2021-01-07 10:10:13 +08:00
测试只能在主干上进行，因为只有主干会部署到生产环境。
|
Select Language