最近提版本发布，出现大量冲突与代码遗漏，有什么比较好的免这些问题的代码开发流程？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 945 天前的主题，其中的信息可能已经有所发展或是发生改变。

我司现在当前的开发流程如下：
主仓 fork 到个人仓
个人仓 dev 分支开发，分为 Bug 修复和新功能开发
-> merge 到主仓 dev
-> 脚本 merge 到主仓 test
-> 脚本 merge 到主仓 release

存在问题，部分新功能开发周期长达 3 到 4 个月，各个功能之间存在着复杂的相互依赖（比如：开发顺序 AB ，B 动了 A 的部分代码但是发布顺序 BA 的这种问题）

想看一下广大 V 友有什么更好更科学的开发流程

第 1 条附言 · 2022-04-21 14:18:05 +08:00

最主要的问题是，3 到 4 个月的开发周期是由于一个重要功能涉及所有的模块和微服务，开发量很大，在未开发完的时候无法提交到测试和发布分支。
因此定期提交到发布分支是不可能的。而在这个大规模功能未开发完成验证无误之前，其他的 BUG 修复和新功能开发，由于此功能的代码提交到了开发分支，也会依赖于这部分代码。从而造成大范围的冲突。

主仓

merge

开发

dev

22 条回复 • 2022-04-22 09:57:16 +08:00

sadfQED2

2022-04-21 11:19:36 +08:00 via Android

第一次见到有 fork 到个人仓这种流程😂直接在主仓建 dev 分支有啥问题吗？

jasondennis12139

2022-04-21 11:21:50 +08:00

@sadfQED2 在主仓每人都建一个 dev 分支？二三十个个人的 dev 分支很难管理啊

sadfQED2

2022-04-21 11:31:13 +08:00 via Android

@jasondennis12139 为啥难管理，你们要管理啥？我们项目都是上千个分支啊

主仓库 release 分支是线上代码
Master 分支是待上线代码
Test 是测试代码

这三个分支开启 merge 保护，不能随意合代码进去，其他分支都随便玩

ccyu220

2022-04-21 11:31:38 +08:00

@jasondennis12139

个人认为：公司项目就不需要像 GitHub 上那样先 fork 再分支的流程。

如同 1# 说的一样，每个功能在主仓建立一个分支，开发根据需求再自己本地分支就好了。

如果有公共文件修改，那就再分支一个需求，merge 之后各人再拉取。

dev 全部开发合并完成之后主分支再按版本合并。

---

综上，不知是否有我还未认知的利弊？我也想学习下其他人的流程是如何。

sadfQED2

2022-04-21 11:32:02 +08:00 via Android

我们是主仓每个需求建一个分支

MoYi123

2022-04-21 11:32:52 +08:00

@jasondennis12139 分支肯定不是按人建, 而是按功能建啊.

Jooooooooo

2022-04-21 11:51:53 +08:00

组内互相了解大家的需求大致的改动啊, 如果有改动同一处功能得提前沟通.

不过你们啥东西需要开发 3 个月? 拆小分开上呗.

starerlloll

2022-04-21 11:53:05 +08:00

我觉得主要问题是 3-4 个月才合并一次代码。。这频率太低了。。。还有 20 多个开发，，

GeruzoniAnsasu

2022-04-21 11:56:16 +08:00

PLEASE （大写强调）最长周期一周

合一次代码

开发周期和代码同步周期完全是两回事，代码同步频率拉起来你遇到的依赖问题全都不存在了

啊，你说没写完同步代码没意义，所以为什么不把任务拆细一点每个可以跑的单元都尽可能小呢，这不就「敏捷」起来了

securityCoding

2022-04-21 12:04:42 +08:00 via Android

@sadfQED2 大仓模式下都在主库搞分支不现实的。

laozhoubuluo

2022-04-21 12:14:45 +08:00

1. 一个开发团队开发一个新功能开发周期 3 - 4 个月说明软件架构有严重问题，绝大多数项目和公司根本接受不了这个周期。建议需求规划端做合理拆分，单个需求用 4 个月不如拆成 20 个需求每个一周会更合理。如果没法拆分那也没办法，说明软件架构积重难返了，如果您不是给金融行业写 COBOL 的工作建议尽快转行。
2. 如果确实积重难返的话也有办法缓解，如果一个需求 7 天之内做不完，那么每周需要找一天 rebase 每个需求的 dev 仓库，保证当时 dev 仓库的内容是主线 Dev 仓库 + 新增内容，可以保证合并期间不那么折腾，相当于牺牲开发进度保证最后合并成功率。

2022-04-21 12:17:48 +08:00 via iPhone

你需要的恐怕是多花点钱雇几个靠谱的人...

zpxshl

2022-04-21 13:04:19 +08:00 via Android

我们主仓几万条分支，还有大量子仓，同样分支爆炸

FranzKafka95

2022-04-21 13:09:26 +08:00 via Android

功能开发三四个月不代表你三四个月提交一次吧，更新一点就提交到远程主仓，其他同事及时更新后 merge 到本地个人分支，大家都这样操作就行了

Building

2022-04-21 13:13:03 +08:00

这就是为什么项目同一个功能的函数能出现好几个的原因，为了方便都手写了一个 private 的给自己专用

cutepig

2022-04-21 13:34:11 +08:00 via Android

我们这边有类似的问题，我们总结原因在于软件设计不好。模块化做的不好。code review 不够。代码修改太随意。
我们正在通过 pull request 做 code review ，希望能够改善情况
仅供参考

jasondennis12139

2022-04-21 14:26:38 +08:00

@starerlloll 肯定不是 3 个月才合一次，是一个很大的新增需求，覆盖了几乎所有模块，并且直接催生了一个新的微服务。期间不停的在向开发分支提交代码，也定期 merge 到测试分支。但是在大范围提发布到发布分支的时候出了问题。

mozhizhu

2022-04-21 14:28:49 +08:00

AB 相互依赖部分抽离出来，做 Base ，每次变化都基于 Base 修改（开发阶段支持 A 、B 单独调用），Base 及时进行测试和内部发布；尽量不要因为 AB 同改，最后合并爆炸

Huozy

2022-04-21 19:37:38 +08:00

不建议 fork 到个人仓。

假定 Master 分支为生产版本代码，测试环境分支 test ，验证环境分支 UAT 。生产发布周期为 7 天一次。
Master 、UAT 、test 分支均受保护，普通开发无法直接提交或合并。

需求 A 从 Master 分支切出一个 dev_A ，需求 B 从 Master 切出 dev_B ，dev*分支都是由开发个人维护的，做相应需求开发。
dev*分支在开发过程中应在每个上线周期后与 mater 进行同步。
开发完成后，发起合并请求至 test ，上测试。由专人进行合并管理解决冲突。

假定上线日为 T 日，那么在 T-7 日时，应将已经测试完成的 dev_A ，由专人合并至 UAT 分支，发布进行验证测试。完成后将 UAT T-7 日版本打包进入待上线，T 日发布。

发布成功后，T+1 日将 UAT 分支合并至 Master 分支，并打上 tag 。
假设 T+2 日，发现重大 BUG ，应从 Master 分支切出 BugFix 分支修复，并直接合并至 UAT 分支进行测试验证再发布。

理论上来说，test 分支上的 feature 功能不会与 UAT 同步，即某些功能上了测试，但可能最终都不会正式发布，那么此时 test 分支已经与 Master/UAT 相差较远，所以 test 分支应该定期删除，重新从 Master 分支切出，再将 dev*合入 test 分支进行测试。

上了 UAT 分支的代码，一定是要发布至生产的，如不发布，需要回退 UAT 分支。

如果你的 A 需求与其他需求代码出现大量冲突或者大量依赖的，需要团队负责人对开发周期进行考量和调整。
git 工作流没有办法完全解决代码冲突，只是尽可能的减少冲突出现。

dlsflh

2022-04-21 21:48:52 +08:00

大家好，请问楼上这些知识看什么书能获得？

duke807

2022-04-22 01:59:42 +08:00 via Android

建議用 gerrit ，不需要 fork 到個人倉，主庫也不會分支爆炸，多人研發同步進度也及時

Bluelion

2022-04-22 09:57:16 +08:00

@dlsflh 去一家用 git 管理代码的公司上两个月班就获得了，或者自己看 git 的资料，搭个仓库自建项目和分支操作下