我们日常开发面临的问题

---

• 紧急修复线上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（功能分支）

• 用于版本迭代（没有拆分到各个feature，一个迭代一个feature/sprintXX），部署开发环境联调（DEV）；
• 基于develop新建；
• 功能发布后删除；

test/sprintXX（功能测试分支）

• 用于功能迭代的测试，部署测试环境（FAT）；
• 输入分支：feature/sprintXX；
• 功能发布后删除；

hotfix/yyyyMMdd（线上BUG修复分支）

• 基于master分支新建；
• 修复上线后，合并回master和develop分支；
• 修复发布后删除；

develop（开发分支）

• 包含最新的功能代码，新建feature/sprintXX 分支的基础；
• 保护分支，禁止PUSH；
• 输入分支：hotfix/yyyyMMdd、test/sprintXX；

release（预发布分支）

• 用于部署预发布环境（UAT）；
• 保护分支，禁止PUSH；
• 输入分支：test/sprintXX；

master（主分支）

• 用于部署生产环境（PROD）；
• 保护分支，禁止PUSH；
• 输入分支：release、hotfix/yyyyMMdd；

分支操作规范

---

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