Git工作流（Gitflow）管理
一、Gitflow工作流概述
工作流（Workflow），指“业务过程的部分或整体在计算机应用环境下的自动化”。是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。
Gitflow，研发工作过程中，通过使用git进行代码管理、版本维护的工作流。Gitflow包含以下几种工作流：
* Centralized Workflow，集中式工作流
* Branch Workflow，分支工作流
* Forking Workflow，Fork工作流
二、Centralized Workflow，集中式工作流
Git的Centralized Workflow非常友好地过度了SubVersion中的集中式工作流，熟悉SVN工作流程的开发者在这方面可以非常容易地掌握Git中的这一工作流。
2.1 Centralized Workflow的概念
像Subversion一样，集中式工作流以中央仓库作为项目所有修改的单点实体。相比SVN缺省的开发分支trunk，Git叫做master，所有修改提交到这个分支上。举个例子，本工作流只用到master这一个分支。
上图描述的是，多人协作开发，代码通过SVN集中式管理，所有人的代码都提交到同一个远程仓库。
上图描述的是，本地代码push到远程仓库后，远程仓库代码的变化。
Reomte表示服务器的远程仓库，Repository表示本地仓库，Workspace是我们的工作区。
2.2 Centralized Workflow的工作流程
- 从远程仓库(central repository)克隆工程到本地仓库(local repository) — git clone
- 在本地仓库编辑文件和提交更新 — git add和git commit
- fetch远程仓库已更新的commit到本地仓库和rebase到已更新的commit的上面 — git fetch和git rebase 或 git pull –rebase
- push本地主分支(master branch)到远程仓库 — git push
2.3 补充
上图是整个项目只有master分支时，本地仓库的结构。
三、Branch Workflow，分支工作流
3.1 Branch Workflow概述
Branch Workflow是本片文章讲述的重点，以下是对Branch Workflow的概念的一些非官方的个人讲述（如有纰漏请指正）。
Git为我们提供了强大的代码分支管理功能，我们可以通过git命令非常快捷方便地创建、删除、合并分支。在我们管理分支的过程中需要遵循一定的流程，这些流程并不是已开始就定义的好的，而是在不断工作实践的过程中得出的宝贵经验。
Branch Workflow的成员如下：
* Feature Branches
* Release Branches
* Maintenance Branches
* Historical Branches
* Master Branch
* Develop Branch
3.2 Master && Develop
Master分支和Develop在git代码管理中式必不可少的两个重要分支，其中Master分支是受保护的默认分支，只有项目的master才能够进行commit等操作。Develop分支是从Master分支迁出来的第一个分支，是以后开发工作中的代码标准。其他开发分支的代码都要merge到Develop分支进行测试和发版。是发开过程中的其他所有分支的父分支。通常情况下，不允许直接修改Master分支，所有的代码都必须要通过Develop分支才能合并到Master分支。
3.3 Feature Branches，功能分支
Feature Branch Workflow的主要思想就是在开发每个功能时都应该创建一个独立的分支而不只是使用主分支。由于每个分支是独立且互不影响，这就意味着主分支不会包含broken code，对持续集成环境是很有帮助的。
Feature Branch Workflow的流程
- 仍然使用远程仓库(central repository)和主分支(master branch)仍记录官方工程的历史
- 开发者每次开发新功能时都创建一个新分支 — git checkout -b
- Feature branches应该推送到远程仓库(central repository) — git push
- 发送pull request来请求管理员能否合并到主分支(master branch)
- 发布新功能到远程仓库(central repository)
3.4 Maintenance Branches，维护分支
Maintenance Branches一般用来对产品进行功能微调和快速修复bug。它是除了Develop分支之外，唯一可以从master分支直接衍生出来的分支；一旦完成修复bug，它应该合并回master分支和develop分支；master应该被标记一个新的版本号。
3.5 Release Branches，发版分支
- release分支主要用来清理释放、测试和更新文档
- 一旦develop分支获得足够的功能来发布时，你可以从develop衍生出一个release分支
- 一旦准备好上架，release合并到master分支并且标记一个版本号
- 另外，还需要合并回develop分支
3.6 Historical Branch
用来记录发版历史的分支，此角色通常由Master分支担任，也可以在每次发版后切出一个分支保存版本代码，现在通常使用tag来进行版本记录。
上图为Gitflow整体示意图，其中HotFix表示Maintenance Branch。
四、参考文献
http://www.admin10000.com/document/6377.html
http://www.jianshu.com/p/91acec85c3a4
http://blog.csdn.net/dengsilinming/article/details/8000622
http://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html
http://www.cnblogs.com/muzhifeike/p/5869217.html
五、Forking Branch说明
Forking Branch在我们日常工作中并不常用到，如果有兴趣可以查看github使用说明。