Google 搜 trunk-based development

@liuchengfeng1 #4 都是在这基础上变，适合自己项目就好。代码冲突是无解的，所以才要将功能拆分到不同文件，用现在的话说，就是分模块。
举例，如果两个人同时要在一个页面做开发，这个页面有个入口文件(index.ts|js)，他们各自写自己模块（ a.ts,b.ts ），在 index.ts 引入这两个文件。基本上冲突就只在 index.ts 出现，只要没人在 index 写大段业务逻辑，可以说基本冲突为零。

按上线计划拆分分支，而不是一个功能一个分支，也不是一个人一个分支。假定上线计划是一周一发布，那 dev 分支放本周需要上线的内容，如果有内容需要本周开发，但不知道什么时候上线，或者你们上线计划经常变化，那建立单独 dev 分支。每个功能做完之前拉代码，做完立即提交。每个人都这样做，问题就不会太大。

随着人数增加和项目复杂度的提升，解决代码冲突已经不是 Git 范筹的问题，要从项目和人员的组织架构上调整，以及工作流程的重新定义。
- 代码结构要更松散，减少耦合。比如拆分文件和项目，如微服务
- 工作内容的重新划分，比如由以前的一坨进行水平或垂直拆分；由以前的水平拆分，变成垂直拆分；或由以前的垂直拆分变成水平拆分

gitlab flow
https://i.imgur.com/dYmUj4U.png

尽量少动别人的代码，动了之后就要马上提交，写好注释。

开发：
1 ， 每个人只能从 dev 合并到自己
2.   功能开发 ok 后，才合并到 dev ，并且有专人审核，必须 build ok

bug：
1 ， 牵头人，拉分支
2 ， 所有相关人员的改进，必须有由牵头人负责审核合并，

冲突是必然的，你们尝试过用插件统一格式吗，比如前端项目的 eslint/prettier 。

如果每个人的编辑器配置不同，哪怕只修改一部分代码，整个文件的格式都会乱，这样冲突会更多

每个人新增功能/处理 bug 就建一个个人分支呀，每个个人分支只做一个相关功能的 bug 修复或只增加一个新特性，然后 review 合并到 dev 分支上，之后删除自己的个人分支，循环往复。

如果有 ci/cd 的话，就每天出个包给到测试那边，测试那边去回归测试

最后从 dev 建个 release 分支，给测试用来做稳定性测试、系统测试等等

https://i.imgur.com/Anjbodi.jpeg

1 个固定分支：

- **master**：主分支。所有的 feature 和 bugfix 分支都从该分支创建。该分支受保护，不允许直接向该分支提交代码

3 个短期分支，完成功能开发之后需要删除：

- **feature/\***：功能分支。用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 master 分支，之后删除该分支
- **bugfix/\***：bug 修复分支。用于修复不紧急的 bug ，普通 bug 均需要创建 bugfix 分支开发，开发完成自测没问题后合并到 master 分支，之后删除该分支
- **release/\***：发布分支。用于代码上线准备，该分支从 master 分支创建，创建之后发布到测试环境进行测试，测试过程中发现 bug 需要开发人员在该 release 分支上进行 bug 修复，所有 bug 修复完后，在上线之前，需要合并该 release 分支到 master 分支。release 分支可以长期保留