我们日常开发面临的问题

• 紧急修复线上BUG，应该如何拉取代码进行改动，直接在develop或master改吗？
• 现在团队有好几个并行开发任务，每个上线时间点不一样，而且是不同的小组负责开发，怎么管理并行任务，如何推送正确代码是一个大问题。
• 每个人对于分支命名不一样，对于命名的理解也千差万别，上线前在发现，分支合并错了。

分支管理的目标

• 代码提交在应该提交的分支
• 随时可以切换到线上稳定版本代码
• 多个版本的开发工作同时进行
• 明确每个分支的功用，做到对应的分支执行对应的操作
• 使用 Git 管理版本迭代、紧急线上 bug fix、功能开发等任务

有一份前辈的参考资料

A successful Git branching model By Vincent Driessen on Tuesday, January 05, 2010

A successful Git branching model

首先这个不是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