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

[Arink]

版本管理流程 a：

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

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

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

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

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

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

[cedoo22]

为保证生产分支质量， 生产分支 必须有个专人去合并的。
有专门测试团队的话，就要求有测试分支。
开发 需要 有一个 锚定的 “最新”分支，一般叫 “开发分支”.
所以，a 的问题 不在版本管理，问题 在 任务分配 /代码组织 上， 覆盖别人代码这种操作 “实习生”以下水平。

[jones2000]

解决冲突，就是每个人改自己的文件， 尽量模块化，然后一个模块一个文件。

[joesonw]

每次合并太大了。不要以人为分支，以 feature/issue/task 为分支开发，勤合并。

[MoYi123]

git 文件冲突不是靠改变合代码流程能解决的, 要靠管理者合理拆分模块, 分配任务.

[pkoukk]

项目管理问题，单体服务太大，模块拆分不合理

[snowhere]

a.问题你也感觉出来
b.直接把测试分支合到生成分支：别人提测的功能没验收就带上去了。。。
c.从测试分支拉开发分支：别人提测的功能没验收有可能影响你的改动。。。
[分支流程这个问题我们团队也讨论过很多次，实践过很多年，最后发现并没有银弹（没有一个毫无缺点的流程）]
我们能做的：
1.合理的划分：项目模块划分合理，减少不同功能模块并行开发时代码的冲突。
2.尽快的合并：使单个开发分支尽可能快地合并回主分支（单个开发分支不做过多的事情、code review 和测试及时），降低并行度。
3.统一：因为没有银弹，所以大家觉得舒服就是最好的流程，不要纠结于寻找银弹。但整个团队一定要统一使用某个流程，才能提高团队效率。

[Morii]

可以去掉预发布分支，通过 devOPS 流程实现预发布环境，靠生产分支的代码部署预发布环境，测试完成后部署生产环境

[simonlu9]

@xylophone21 标准 git flow 不适合所有公司，上面的流程是改造过的和 gitflow 是有差异的，比较适合大部分公司，大部分公司只有一套测试环境，存在同时提测多个功能，只能合并到 test 分支，这个是成本最少的，不可能一人一套环境测试，develop 这个分支在 a 流程是没有用的，test 分支已经具备该功能，新同事开发是基于 master 分支拉代码的，开发完才合并到 test ，这个时候就和 gitflow 流程很像了，但是修 bug 还是再自己的分支上面修改，然后不断地合并到 test 分支，直接测试通过，release 分支是到了预发布环境，这个时候一般 bug 都比较少了，测试会重新跑一次流程，这个时候可以直接在 release 上面修 bug,因为差不多可以上线了，开发分支基本没什么用了，测试在 release 分支测试完成了就可以把 release 分支合并到 master,这个时候代码才是最稳定的

可以看下我之前提问的帖子

[Arink]

@yyf1234 一个项目，多个需求，并行开发，不是多人来发一个任务，是多人开发一个项目

[Arink]

@simonlu9 有道理，给你加个爱心❤️

[Arink]

@wolfie 好像是这样，上次就是被实习生给覆盖了同事的代码，还好同事自己的分支上有保存

[Arink]

@yc8332 有道理，是我自己的想法错了，现在想了想，流程 a 没问题，有问题的是人

[Arink]

@simonlu9 好的 我看看

[noobakong]

a 流程的过程中可以加一个公共分支
比如从 mater 最新分支 建一个 版本的公共分支 20221216 分支

然后开发者 A ，开发者 B ，开发者 C 从 20221216 切各自的功能分支进行开发
开发者 A 切分支 feature/aaaaa
开发者 B 切分支 feature/bbbbb
开发者 C 切分支 feature/ccccc

开发完毕 下面 ABC 要做的就是把代码合到 20221216
怎么合 是有讲究的

为了保证 ABC 各自功能的 commit 合到 20221216 后是线性的
如何合 有讲究：以 A 为例
在 feature/aaaaa 分支 rebase 最新的 20221216 分支 保持 A 的 commit 始终奠基在最新的 20221216 分支上
然后再在 20221216 分支 merge feature/aaaaa

这样的话 20221216 分支上始终是一条线性的直线 各自的功能 commit 紧凑在一起 非常清晰

然后就是测试 预发 生产的发布了 因为大家在 20221216 各自 merge 自己的功能分支时 都是解决了冲突的
所以 20201216 分支 merge 到 测试 预发 生产分支的时候 是没有任何冲突的

这样是不是就会清晰很多
---------------------------------------------
相关的几个点：
1. 弄清楚 rebase 和 merge 的区别，有的团队只会 merge 导致分支混乱 和织蜘蛛网一样 难免会有各自冲突，有的一个冲突要解决 n 遍 丢代码更是家常便饭

2. git push -f 慎用 但是必要时要用

3. git 操作过程中不要靠猜 每个人 要清晰的知道自己敲的每一个 git 命令 不能明确自己在做什么的时候 立即停止 请教熟悉 git 的人

4. 公共分支 的代码 自从建立之后 原则上应该都是各自的个人开发分支 merge 过去的产物

5. 善用 git rebase -i 交互式命令 去整理自己的 commit

[McVander]

@evada 对我看到 a.4 和 a.5 也有点疑问，我觉得也是整体一起合并，如果都是单独合并的话，那么预发和测试分支可能节点会出现不一致的现象。

[imherer]

问下 如果按照流程 a： 当功能开发完合到测试分支后，QA 测出 bug 了在哪个分支改呢？

[ltruntu]

方案 b 太理想了，假如只有一套测试环境，那 1 个功能提前开发的测试完不上线的 ，就做不到了

[Arink]

@noobakong 感谢！

[duzengjie]

@imherer 问题出在哪个分支就在哪个分支改动,如果是线上 bug 也是从生产分支拉出一个分支出来改动,然后 megre 到测试环境

[imherer]

@duzengjie 那现在是在测试分支发现的 BUG 就在测试分支改，完了还得把这个修改提到开发分支？（因为最后是 QA 测通了，会把开发分支的内容合到主干）