我觉得我们公司的版本管理流程有问题，但我能力不足，我不知道我的想法是否正确，请大家帮忙看看

[Arink]

版本管理流程 a：

1. 公司有三个重要分支，测试分支，预发分支，生产分支。
2. 每个人的开发分支是从生产分支拉的，每个人开发完自己的需求后合并到测试分支。
3. 如果有冲突，找到对应的开发者解冲突，合代码。
4. 测试分支没问题后，再把自己的分支合并到预发分支，有冲突重复第三步
5. 预发分支没问题，再把自己的分支合到生产分支，这时候就算你的需求上线了

我觉得这个流程会浪费相当多的时间在解冲突上，并且这个流程也不合理，已经出现过了别的同事的代码被误操作给覆盖了的情况

版本管理流程 b：有三个分支，版本分支，测试分支，开发分支

每个版本开发前从测试分支拉一个版本分支，大家的开发分支从这个分支来拉代码，开发好后合到版本分支，需要测试的话直接把版本分支合到测试分支，这个版本的需求都测试号后，没问题直接把测试分支合并到生产分支，这样就完成了一个版本的更新

版本管理流程 c： 就两个分支，测试分支和生产分支，我们开发分支是从测试分支拉出来的，自己的需求开发好后合到测试分支，测完没问题再把涉及自己开发的那几个提交合并到生产分支，这样就完成了一个需求的上线

我感觉 b c 都挺好，a 让我感觉很扭曲，想听听大家的看法

[holy_sin]

冲突太多是代码设计不合理导致的吧

[waterlaw]

阿哲
我们这边是 master(生产环境)分支，release(准生产)分支，uat(测试环境)分支，以及 feat (需求)分支。

每次开发需求，从 master 拉出一个 feat, 再从 feat
拉出一个属于自己的 dev 分支，改好了提到 feat,
然后再提 feat 到 uat 的 mr,

测试好了，再从 master 拉出一个 release 分支，merge 我的 feat 分支，上线后再把 release 合并到 master, 然后未上线的 feat,
从 feat 拉出临时分支，merge master, 再提一个到 feat 的 merge 。

[xylophone21]

@simonlu9 好的, 我的问题就是这个并不是 git flow.

另外你提到 develop 分支没有用,所有功能都合入 test 分支,(再合并到 master 分支上线),感觉这其实更像 gitlab flow. test = master, master = production/stable. 但问题还在 gitlab 分支是从 master 开发,而非 production/stable. 也就是违背了上游优先原则.

[simonlu9]

@xylophone21 并不是 test 合并到 master,是 release 合并到 master ，release 是由多个或一个 feature 分支测试完成合并过来的