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

[Arink]

版本管理流程 a：

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

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

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

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

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

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

[muyujinxi]

我感觉这个没有绝对正确，自己用着顺手就行。git flow 也不是说不能有测试分支，另外我想到两个习惯：
1. 加一个原则,就是不是所有人都有权限去合并生产分支，一定是一个熟悉当前上线所有功能的人或者就指定一个人去负责
2. 生产分支可以是上线通过后再合并，这是测试分支当成一个缓冲也是可以的

[simonlu9]

b 很好奇，你说的 b 有什么优点，开发分支从测试分支拉出来，不觉得有问题吗。测试分支包含了其他人代码，你在测试分支拉出来开发完成，万一别人的代码有问题，你的代码一样有问题，暂时解决不了，上线就不干净了，有风险

c 更加无语，还是会存在一样的问题

a 流程没问题，也是最稳定的，预发布存在的一样就是 a,b,c 同事开发，同时测试，但这次发版我只需要 a,b 功能，这就体现了价值所在，只需要 ab 分支合并到预发布分支就可以了，
冲突在所难免，测试分支解决过的冲突，可能到预发布又要解决一次，尽量避免在同一个地方修改太多代码

[changepll]

为什么这么多回复没说说到那张经典的图呢. 最佳实践那张图

[evada]

我觉得 a.5 和 a.4 可以优化一下，如果这次测试分支或者预发布的都是需要上线的，可以直接把测试或者预发布分支往前合并。如果有不需要上线的，才需要单独合并开发需求的分支。

[TArysiyehua]

a 流程是最的，你觉得解冲突麻烦，是项目管理的问题。
因为正常来说，你和同事开发的功能是不一样的，模块不同，分散到不同的地方。哪怕改到同一个基础类，也是少量的部分，冲突几乎是很少的。
如果你开发的功能较为庞大，功能很多，开发周期很长，时间长了冲突也会多，一般这种情况我们会做自己的分支，每做完一个小功能，自己主动合并一下主分支，这样就能避免长时间没有合并主分支代码导致大量的冲突

[brader]

我们公司目前采用的就是 A ，没觉得有什么问题，而且流程也很方便，用的阿里云效发布，采用分支合并模式，我们点点鼠标，就可以很方便的操作上线、下线 某个分支的功能

[caicaiwoshishui]

流程 a 符合 git-flow ，没有问题

冲突太多，那你应该考虑项目是怎么管理的？我能想到一个服务冲突很多的情况一般是配置文件 /路由文件这些共用的文件。

新功能开发，一般都有新的文件夹和文件吧？

hotfix 也不会同时多人 hofix 产生冲突吧

还是建议你项目优化下文件夹管理，单体项目能拆就拆出来。

[janxin]

https://trunkbaseddevelopment.com/

分支多会有很多问题，尤其是开发分支越久越难合并进入版本分支。如果你们滚动发布的话可能问题会更小一点，但是功能开关，个人能力和流程管理都会有一些额外要求。

[wolfie]

从 test 分支 checkout feature 可还行。。。。。

a 一点毛病没有，频繁解决冲突是因为 跟 base 分支太久没同步了。覆盖别人代码是太菜了。

[xylophone21]

用 github flow 比较多, 但如果我没有理解错,git flow 每次是从开发分支拉出来开发, 而不是从生产分支拉. 也就是”上游优先”原则. op 的操作每次从生产分支拉, 大致相当于"下游优先"了, 很多已经在上游修改过的东西, 你一拉分支,就又没有了,可能不自觉又从新改了一遍, 所以冲突很多.

如果你们有大量功能开发持续时间很长, 而且和现有模块又高度相关而不是新写一个模块(其实我有一点怀疑, 因为这里有 3 个关键词, 大量,持续时间很长,高度相关, 换句话说你们经常性的把已有模块翻来翻去 -- 如果是重构, 不符合大量, 如果是原代码结构比较差, 总要改则不符合时间很长; 如果结构好,每次都是扩展一个子类新写一个模块, 不符合高度相关), 那么可以尝试一下 gitlab flow, 否则 github flow 真的很简单好用.

>> 每个人的开发分支是从生产分支拉的，每个人开发完自己的需求后合并到测试分支。

[xylophone21]

@wolfie
@caicaiwoshishui
@brader
@TArysiyehua
@simonlu9
@NerbraskaGuy
@biubiu001
@karott7


https://gitee.com/jadepeng/pic/raw/master/pic/2021/2/2/1612267487337.png

看到几位说这个符合 git flow,但如图 git flow 中的 feature 分支(即每次开发)都是从 develop 分支来的. 不知道我哪里理解错了.

[yyf1234]

> 我觉得这个流程会浪费相当多的时间在解冲突上

为什么会有这种情况，你们是多人开发一个任务吗？

[wolfie]

@xylophone21
例子 a ，3 个 workflow 中哪个都对不上。

这个增加了个共用的 test 分支，小公司更容易上手。

[Dlin]

大多数说的对，a 才是合理的，bc 都不合理，bc 导致的问题很多。a 如果合并冲突很多那是开发人员开发方式、任务分配（要动的代码）、以及沟通上（如果你要改动很大，你可以通知他们先合并你的改动，或是 cherry-pick 一下你的那个更改）的问题，流程没有问题。

[evilwk]

看你的描述，自己的分支合并到测试分支，应该合并最新的测试分支到自己的分支，没问题之后再合并回测试分支。大家都不想处理合并问题，直接强行合并到测试分支，流程并没有问题，有问题的是人。

[yc8332]

感觉你们现在的流程没问题。只是你们没有及时合并代码吧。而且冲突是同时修改的同一个文件的相同部分。不然正常都很好解决。如果是这个问题，不是应该开发相同功能的人同用一个分支吗？

我们目前用的也是比较基础，并没有用 git flow
1. develop 分支(测试分支，测试环境用的代码, feature 合过去的)
2. feature*分支，新版本功能的分支(你自己本地可以有一个单独的 feature 分支，再合并到共用的 feature 分支，或者直接在公共分支开发都行，正常不强求)
3. pre 分支(预发分支)
4. master(线上分支)

feature 都是 master 出来的。
pre 是 feature 合过去的，如果出现上 pre 又不发的会回退
master 以前也是 feature 合并过去的，目前基本就是直接 pre 合过来，就不会有冲突了，不然如果和 feature 冲突可能要再次处理冲突。

至于说代码被覆盖，弄没了。这个任何方式都会出现，只要有冲突，处理的人不好好处理，肯定是有问题的。这个问题在人不在流程

[DCELL]

a: gitlab flow
c: github flow
b: 自己琢磨的 flow

[wdssmq]

Git 工作流程 - 阮一峰的网络日志
http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

[zoharSoul]

不需要测试分支和预发布分支

只需要测试环境和预发布环境...
某个功能分支, 验证无误后直接合 master 即可

[learncat]

考虑职责划分。

每个 model 一般 2 到 3 个人编写。 不能随便改别人的 model 的代码。 避免 较多的人交叉写同一个模块。

经常更新主干代码到本地分支，及时发现别人的变化。