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

[Arink]

版本管理流程 a：

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

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

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

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

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

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

[yongjing]

提建议也要看能力足不足吗？

[Arink]

@yongjing 抱歉，让你误会了，我都意思是我觉得自己挺菜的，不知道自己的想法对不对，所以想请大家看看，我默认大家都是比我强的，所以才这样表达，如果让你感觉到了不舒服，非常抱歉！

[kaf]

git flow,可以看看这个 https://www.gitkraken.com/learn/git/git-flow

[yunxi]

关于 b,c 我觉得你忽略了一个问题，测试分支有可能堆积多个待测功能，如果开发分支从测试分支拉，你开发的功能已经测试完成可以上线了，但是你且分支的时候包含的一个待测功能还没有测完，导致你的功能也无法正常上线。
你们目前使用的管理流程感觉是没有问题的，当然会出现冲突的情况，但应该是比较低频的问题。如果频繁出现冲突，应该考虑是不是任务划分存在问题。

[liuzhedash]

假设冲突情况很少，是不是就没啥问题了？
如果是的话，那么问题是在代码冲突频繁上面，而不是版本流程上。

[karott7]

A 流程不就是 git flow 推荐的流程么？我没怎么多人合作过，我目前就用 A ，一个人肯定是没啥问题的，多人协作频繁冲突我觉得还是任务分配不合理吧，公用组件或者工具方法建议更改前群里问下再开发，或者独立出来开发一个包。

[mxT52CRuqR6o5]

看具体场景了，如果是想极致敏捷，每个需求开发完马上就上一次线，那就只能这么做了，以浪费相当多的时间在解冲突上为代价来最小化需求开发完成后等待上线的这段时间

[ysc3839]

我觉得问题在“合并”，为什么预发分支和生产分支不是直接 fast forward ，正常来说应该只有一条主线，不同分支在不同的进度才对。

[biubiu001]

版本 a 是合理的，例如，测试分支存在这三个未能上线的功能，你负责的功能要比测试分支的功能提前上线，要是基于测试分支开新分支，那就把不能上线的功能给上线了

[Arink]

果然还是要多问，我都不知道 git flow ，感谢！

[Yuesh1]

这个帖子要是昨天能看到该有多好，正好昨天面试被问到 git flow ，真是孤陋寡闻了，被问住了

[Arink]

@biubiu001 原来如此，我都没想到这些情况，感谢！

[xuanbg]

分支太多不是好事，什么测试分支和预发分支完全可以不要。
除了主分支，我们只有两类分支，说类不说个，是因为同类型分支可能同时存在多个。
一类是功能分支，从主分支分出来专门用于新功能开发的。提测就打个版本 TAG ，自然就自动发布到测试环境了。有 bug 就继续修，修完再打 TAG ，自动发布后继续测，测完没问题，合并到主分支并且删除功能分支，主分支上打验证版本 TAG ，发布到预发环境验证。验证完打正式版本 TAG ，自动上线。
第二类是修线上 bug 的分支，专门从主分支上分出来修 bug 用的，流程和功能分支是一样的。上线后，主分支要往所有功能分支上合并一次，这样功能分支的代码就和主分支不冲突了。如果修 bug 过程中有新功能上线，那么主分支也需要合并到修 bug 分支一次，以免产生冲突。

正常情况下几乎没有冲突，只有一种情况，冲突无法避免。就是功能分支的某个文件在其他临时分支上也被改变了。这时，就只能把相关的人都叫上，大家一起人工解决了。但这种情况几乎没有，各新功能之间不会有什么文件冲突，如果要改动已有代码，都是先走修 bug 流程，在主线上把新功能当 bug 先修了，而不是在功能分支上直接改已有代码，就不会冲突了。

[hellojl]

a 流程中，如果能保证代码的流向是从测试分支 -> 预发分支 -> 生产分支，会减少一些冲突的产生。即个人分支从测试分支拉出，验证通过后合回到测试分支；测试分支中，本期要上线的功能合入到预发分支里（可以用 cherry pick ）；验证通过后，再将这部分代码合入到生产分支。

另外个人分支建议使用短生命周期的 feature 分支，并且在合并前，多进行对目标分支的 merge 或 rebase ，可以减少冲突的产生。

除了 Git flow 外，如果更新迭代的频率比较高的话，GitHub flow 或者主干开发也可以尝试一下，后两者使用更简单的分支模型，但是对 DevOps 和测试相关的基础设施要求比较高。

[darkengine]

关键是不能所有人都有权限合并到生成分支

[L4Linux]

流程上是合理的，就是解冲突的人还是提交代码的人比较好。

[xuanbg]

@xuanbg 其实避免代码冲突总结起来就一个原则：

禁止在临时分支上直接修改线上代码！

线上代码的变更要走修复 bug 的流程且先上线，然后通过从主分支合并到临时分支的方式去更新临时分支的线上代码。

[liuliancao]

按 Srint 每个月或者 m ，划分成若干个双周
我们是每个双周从 nr_test 拉一个新的双周分支包括 bug_test 分支
nr 从 nr_test 合并
各个版本从 nr 析出

[857681664]

一种比较合理的流程是所有人都从生产分支切需求分支，开发完毕后都合并到需求分支里，后续所有的合并都是 fast- forward ，也就是测试分支往预发分支合并，预发分支往生产分支合并，这样就能避免需要手动提交 3 次的问题，但这种方式有个前提是，所有同事并行开发的需求都是在同一个版本上发布，不然就会把不该发布的提交发布了。

还有一种方式是，对于比较大的需求，通常来说是会跨越好几个版本，或者涉及好几个模块，几个组的那种，单独开一个测试环境去测试，直到一切都 ok 后，合并进入测试分支，然后继续通过上面的方式发布，这种方式依赖非常强大的基础设施。需要为一个需求单独开一整套环境（前端后端数据库，各种依赖中间件）

[NerbraskaGuy]

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 的代码。 避免 较多的人交叉写同一个模块。

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

[cedoo22]

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

[jones2000]

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

[joesonw]

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

[MoYi123]

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

[pkoukk]

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

[snowhere]

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

[28Sv0ngQfIE7Yloe]

可以去掉预发布分支，通过 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 测通了，会把开发分支的内容合到主干）

[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 分支测试完成合并过来的