一、版本发布 git flow
参考： www.ruanyifeng.com/blog/2012/0...
Git flow的优点：是清晰可控。
缺点1：是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。
缺点2：更大问题在于，这个模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。但是，很多网站项目是"持续发布"，代码一有变动，就部署一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。
二、持续迭代（以github为代表）
功能分支合并进 master 分支，必须通过Pull Request（Gitlab里面叫做 Merge Request ）
Github flow 的最大优点：就是简单，对于"持续发布"的产品，可以说是最合适的流程。
缺点：在于它的假设，master分支的更新与产品的发布是一致的。也就是说，master分支的最新代码，默认就是当前的线上代码。经常，master一个主分支就不够用了，你不得不在master分支以外，另外新建一个production分支跟踪线上版本。
三、版本发布和持续迭代的结合 （gitlab为代表）
（1）持续迭代
对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是production。
（2）版本迭代
对于"版本发布"的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。
以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
四、多版本的版本发布， multi git flow
(1) main用于版本发布。
Main上代码永远是测试完毕的，并且需要打相应的tag，比如2.0.0-20250101 （版本号 + 日期）
（2）version分支,相当于develop分支。
根据产品文档需求，比如2.0.4，就产生version2.0.4分支，这个分支是基于当前master的tag 2.0.3最新版本的。
测试过程中：使用持续合并到某个version分支。
（3）个人本地开发分支
基于version分支，新建个人本地的分支。
合并到version分支时候，需要提交 merge request ，指定相应的负责人 code review 每个commit和文件。
备注：
另外，跟开发分支有冲突并且只能手动解决的时候，gitlab会拦截，提交不了merge request, 可以在网页端解决，更建议在vscode端解决。
（4）bugfix分支
基于master，新建一个bugfix分支，修复验证后，合并入master。并且打上最新日期的tag，比如比如2.0.0-20250207 （版本号 + 日期）
五、协作机制
（1）使用机器人提醒merge request，除文案修改外，其他都需要pull request或者说merge request。
（2）安排任务时候，记得预留 codereview时间， 尤其是项目带头人。
形式1：可以结对codereview。
形式2： 项目带头人codereview 小组成员的代码，项目带头人自己的代码安排给有时间的小组成员的代码