我们日常开发面临的问题
- 紧急修复线上BUG，应该如何拉取代码进行改动，直接在develop或master改吗？
- 现在团队有好几个并行开发任务，每个上线时间点不一样，而且是不同的小组负责开发，怎么管理并行任务，如何推送正确代码是一个大问题。
- 每个人对于分支命名不一样，对于命名的理解也千差万别，上线前在发现，分支合并错了。
分支管理的目标
- 代码提交在应该提交的分支
- 随时可以切换到线上稳定版本代码
- 多个版本的开发工作同时进行
- 明确每个分支的功用，做到对应的分支执行对应的操作
- 使用 Git 管理版本迭代、紧急线上 bug fix、功能开发等任务
有一份前辈的参考资料
A successful Git branching model
By Vincent Driessen on Tuesday, January 05, 2010
首先这个不是Git或Github的官方资料，只是这位前辈的个人总结，也仅仅是适用当时这位前辈所在的Team的工作模式，并不适用于目前团队的工作模式。所以，在参考Git Flow的资料后，我们制定了自己的团队规范。
我们的规范
feature/sprintXX
- 作用：新功能迭代开发
- 部署环境：开发环境 DEV
- 创建：基于develop分支
- 是否删除：功能发布后删除
- 限制：无
test/sprintXX
- 作用：新功能迭代测试
- 部署环境：测试环境（FAT）
- 创建：基于feature分支（每次提测前，feature merge develop代码，feature再合并到test）
- 是否删除：功能发布后删除
- 限制：No Push / 开发人员Merge
hotfix/yyyyMMdd
- 作用：线上问题修复
- 部署环境：测试环境（FAT）
- 创建：master分支（修复上线后，合并回master和develop）
- 是否删除：修复发布后删除
- 限制：无
develop
- 作用：包含最新的功能代码，新建feature/sprintXX 分支的基础
- 限制：No Push / 开发人员Merge
master
- 作用：稳定代码
- 部署环境：生产环境（PROD）
- 限制：No Push / 少部分有权限的可Merge
分支操作规范
feature/sprintXX分支下使用rebase
解决提交路线图清晰问题，git pull默认是merge操作，可以使用如下命令进行rebase
git pull --rebase
#也可以做全局配置
git config --global pull.rebase true
git config --global branch.autoSetupRebase always
分支合并使用 no-ff
解决fast-forward 合并的路线图问题，这种 merge 的结果就是一条直线，无法明确看到切出一个新的 feature 分支，但是使用 no-ff就可以明显看出新feature分支的合并路线图
# 合并sprint01 到 develop 分支
git merge --no-ff feature/sprint01
