@0xD800 说的太对，耦合太重了，或者文件太大导致一个人搞不定。

没有比较好的方案，实际上 git 只是个工具，还是要靠人治，制定 git 工作流，其他的分支 要多从源分支反合并，才能减少冲突，而且也无法确保一定就不出错，git 工具是不会出问题的，只要有人参与做的事情，出问题都是人的问题，

建议了解下主干分支+特性开关管理模型，最近两个大项目实践下来感觉还不错。

https://mp.weixin.qq.com/s/m4N8ugQEM-StNRHfshexXJ8KA

每天自动把主干分支反向 merge 到各个 feature 分支, 有冲突尽早解决.

如果是多版本发布策略，用 1 楼图片那种，如果是单版本滚动发布就用 gitlab flow

每个小时合并一次主开发分支, 这样就很轻松了

TBD + Feature Toggle

一个 master 分支，一个 dev 分支，开发都在 dev ，自己 fork 一个仓库提 mr 合 dev ，有 committer 和特性责任人检视，自验完打 tag 出包转测试，每个人提交代码要保证自验和正常启动，每次提交不能超过 500 行。发布时从 dev 合 master 。
线上补丁从 master 拉分支出来修改后双合 master 和 dev 。

参考 Releaseflow https://suraciii.github.io/posts/release-flow/

重点：
* 一个主干
* 快速集成
* 自动化测试
* 不要合来合去的

简单的项目 gitflow

更快速或者高效的团队可以考虑 github-flow 或者 gitlab-flow 。

有奇葩要求的，也可以自己团队商量一套实践。

但是、但是，总会有 2B 的领导或者不写代码的“技术牛人”，跳出来要求“统一”“规范”，最后搞出个缝合怪。