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

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

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

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

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

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

@jasondennis12139

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

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

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

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

---

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

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

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

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

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

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

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

合一次代码



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


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

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

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

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

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

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

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

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

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

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

不建议 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 工作流没有办法完全解决代码冲突，只是尽可能的减少冲突出现。

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