# 一、背景
一个团队使用Git时必须有一个使用规范，让大家有效地合作，使得项目井井有条地发展下去。
在业界里，这个规范有一个词是workflow，翻译一下就是工作流程的意思。
工作流程都是基于一个前提："功能驱动式开发"（Feature-driven development，简称FDD）。
它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
常见的工作流程有三种：Git flow、Github flow、Gitlab flow。
这里先来看看Git flow。
# 二、两个主干
最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。
它最主要的特点有两个。
首先，项目存在两个长期分支：主分支master、开发分支develop。
master分支用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；不允许在该分支直接提交代码。
develop分支用于日常开发，包含了项目最新的功能和代码，所有开发都在 develop 上进行。一般情况下小的修改直接在这个分支上提交代码。
创建develop分支：
git checkout -b develop master
发布到master：
git checkout master
git merge --no-ff develop
# 三、三个分支
项目存在三种短期分支：功能分支（feature）、补丁分支（hotfix）、预发分支（release ）。
一旦完成开发，它们就会被合并进develop或master，然后被删除。
## 1. 功能分支
功能分支是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
功能分支的名字，可以采用feature-*的形式命名。
创建一个功能分支：
git checkout -b feature-x develop
合并到develop：
git checkout develop
git merge --no-ff feature-x
git branch -d feature-x
## 2. 预发布分支
预发布分支是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。
如果有 bug 就直接在这个分支上修复，确定没有问题后就会合并到 master 分支。
创建一个预发布分支：
git checkout -b release-1.2 develop
测试通过，合并到master分支：
git checkout master
git merge --no-ff release-1.2
# 对合并生成的新节点，做一个标签
git tag -a 1.2
由于有可能有修改，需要合并到develop分支：
git checkout develop
git merge --no-ff release-1.2
最后，删除预发布分支：
git branch -d release-1.2
## 3. 修补bug分支
修补bug分支是软件正式发布以后出现了BUG，进行紧急修补的分支。
修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
创建一个修补bug分支：
git checkout -b fixbug-0.1 master
修补结束后，合并到master分支：
git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1
由于有变更。需要再合并到develop分支：
git checkout develop
git merge --no-ff fixbug-0.1
最后，删除"修补bug分支"：
git branch -d fixbug-0.1
# 四、总结
Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。
更大问题在于，这个模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。但是，很多网站项目是"持续发布"，代码一有变动，就部署一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。
# 五、其他
对于 Git flow，需要维护五个分支，有点复杂。
所以 Github 想了一个简单的管理方法，叫做Github flow。
它只有一个长期分支，就是master，另一个分支叫做开发分支。开发完成后合并到master分支。
不过这个合并是通过发起 Pull Request 方式合并的。发起Pull Request后负责人会收到通知，然后可以评审和讨论你的代码，通过了就合并到 master。
另外由于Github flow有点太简单了，不太安全。
所以有人想了一个折中的管理方法，叫做Gitlab flow。
它有三个分支：开发环境master分支、预发环境pre-production分支、生产环境production分支。
开发环境和生产环境很容易理解，预发环境指的是发布前的一个环境，相当于发布前的一个测试环境。
# 六、最后
Git 的分支比较强大，怎么管理分支主要看我们的人为约定。
Git flow管理方法最复杂，涉及到五种分支：主分支、开发分支、功能分支、补丁分支、预发分支。
Github flow管理方法最简单，只有两种分支：主分支、开发分支。
Gitlab flow是一个折中，有三个分支：开发环境、预发环境、生产环境（主分支）。
其实，我们工作中可以使用另外一种管理方法：主分支、开发分支、补丁分支、预发分支
相比Git flow少了一个功能分支，相比Gitlab flow多了一个补丁分支。
功能分支和开发分支有点重复所以合并；而补丁分支又是不可缺少的，毕竟线上出问题要紧急修复也很常见，此时还不能把开发的功能带出去。
这种管理方法我们就成为 Sky flow吧，中文含义是天空流。
参考资料：
https://www.ibm.com/developerworks/cn/java/j-lo-git-mange/index.html
https://www.git-tower.com/learn/git/ebook/cn/command-line/advanced-topics/git-flow
本文首发于公众号：天空的代码世界，微信号：tiankonguse-code。
我是谁：
我是天空，这里有技术、理财、读书、电影、以及一个程序员的生活。谢谢你的阅读。职业上、理财上、生活上，你有问题无法抉择时，都可以加我微信进行交流。
我是观点：
如果你认为这篇文章对你有启发，可以进行一次有深度的思考并留言，也可以带着这个想法转发朋友圈，时间久了，你会发现自己是一个会独立思考的人。
最近文章：
GIT的基本命令
❖ 点赞、留言、分享朋友圈 ❖
❖都是对笔者的一种支持 ❖
