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

yongjing

2022-12-15 11:44:24 +08:00

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

Arink

2022-12-15 11:46:17 +08:00

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

kaf

2022-12-15 11:48:50 +08:00

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

yunxi

2022-12-15 11:48:58 +08:00

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

liuzhedash

2022-12-15 11:54:11 +08:00

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

karott7

2022-12-15 11:55:00 +08:00

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

mxT52CRuqR6o5

2022-12-15 11:55:51 +08:00

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

ysc3839

2022-12-15 11:59:03 +08:00

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

biubiu001

2022-12-15 11:59:56 +08:00

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

Arink

2022-12-15 12:00:55 +08:00

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

Yuesh1

2022-12-15 12:03:24 +08:00

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

Arink

2022-12-15 12:07:30 +08:00

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

xuanbg

2022-12-15 12:45:12 +08:00

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

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

hellojl

2022-12-15 12:50:37 +08:00

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

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

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

darkengine

2022-12-15 12:51:59 +08:00

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

L4Linux

2022-12-15 12:57:09 +08:00

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

xuanbg

2022-12-15 13:06:35 +08:00

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

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

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

liuliancao

2022-12-15 13:40:54 +08:00

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

857681664

2022-12-15 13:50:57 +08:00

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

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

NerbraskaGuy

2022-12-15 14:11:03 +08:00

A 挺常见的吧，就是多人并行开发提交到测试分支确实会经常解决冲突