git分支模型探讨
在阅读本文之前，假设你已经熟悉了git的常用命令，并且对git的分支模型有了基本的了解。
基础常用命令：
- git clone
- git add
- git commit
- git push
- git checkout
- git branch
- git fetch
- git merge
- git pull
- …
关于git分支模型，建议先阅读如下资料：
如下是网络上流传比较广泛的一个较为成熟的git分支示意图，基本能满足一般团队或个人进行代码管理。
但每个team都有自己的需求和特点，生搬硬套不一定是合适的，和同事花1个多小时的时间讨论了一下，认为适合我们team的分支模型，大致如下。
需求背景
主要的需求如下：
- 能支持日常迭代开发、紧急线上bug修复、多功能并行开发
- 大概50人左右的团队，平日迭代项目较多，且周期短（1~2周一个迭代）
- 能够通过tag重建整个系统
- 支持code review
- 所有上线的代码必须都是经过测试保证，且能自动同步到下一次的迭代中
- 能和公司的项目管理/持续集成系统整合
分支模型说明
1. 日常迭代
1.1 流程说明
- 项目负责人先初始化仓库
- 拉分支，同时包括develop和release分支
- develop分支开发完成后，提交pull requests到release分支
- 进行code review，通过则merge到release分支
- 在release分支上进行build和生成上线包
- 部署上线包，上线完成后再merge到master，并打tag
1.2 后续迭代流程
- 从master上一次tag处拉出分支，同时包括dev和release
- 在dev上进行开发和提交
- 开发完成后，提交pull request到release分支
- 进行code review，通过则merge到release分支
- 在release分支上进行build和生成上线包
- 部署上线包，上线完成后再merge到master，并打tag
2. 在正常迭代同时有紧急线上问题修复
- 迭代分支同上
- 同时再拉出hotfix开发和hotfix_release分支
- 此时迭代和hotfix分支并行开发
- 如果hotfix开发完成，并在hotfix_release分支进行提测并上线
- 那么在迭代开发进行pull request前，应该要求先从master分支进行一次merge
3. 多功能并行
理论上和hotfix分支模型没有区别。
相关规范
- 开发人员不应该操作master分支
- 由每个迭代或项目的负责人来进行code review和进行merge操作
- 各开发分支和release分支均应该push到远程仓库
- 日常迭代和release分支在开发完成后应该被删除
- 多人协作，应该使用同一个远程分支
- 每次发起pull request前，都需要先从master分支merge代码