一. 什么是Gitflow
在工作场合实施Git的时候，有很多种工作流程可供选择，此时反而会让你手足无措。本文罗列了企业团队最常用的一些git工作流程，包括Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow。愿以此文抛砖引玉。
在你开始阅读之前，请记住：这些流程应被视作为指导方针，而非“铁律”。我们只是想告诉你可能的做法。因此，如果有必要的话，你可以组合使用不同的流程。
- 它是怎么工作的？
Gitflow流程仍然使用一个中央代码仓库，它是所有开发者的信息交流中心。跟其他的工作流程一样，开发者在本地完成开发，然后再将分支代码推送到中央仓库。唯一不同的是项目中分支的结构。
-
用于记录历史的分支
Gitflow使用两个分支来记录项目开发的历史，而不是使用单一的master分支。在Gitflow流程中，master只是用于保存官方的发布历史，而develop分支才是用于集成各种功能开发的分支。使用版本号为master上的所有提交打标签（tag）也很方便。
图2
事实上，Gitflow流程就是围绕这两个特点鲜明的分支展开的。
-
用于功能开发的分支
每一个新功能的开发都应该各自使用独立的分支。为了备份或便于团队之间的合作，这种分支也可以被推送到中央仓库。但是，在创建新的功能开发分支时，父分支应该选择develop（而不是master）。当功能开发完成时，改动的代码应该被合并（merge）到develop分支。功能开发永远不应该直接牵扯到master。
图3
注意：组合使用功能开发分支和develop分支的这种设计，其实完全就是Feature Branch Workflow的理念。然而，Gitflow流程并不止于此。
-
用于发布的分支
图4
一旦develop分支积聚了足够多的新功能（或者预定的发布日期临近了），你可以基于develop分支建立一个用于产品发布的分支。这个分支的创建意味着一个发布周期的开始，也意味着本次发布不会再增加新的功能——在这个分支上只能修复bug，做一些文档工作或者跟发布相关的任务。在一切准备就绪的时候，这个分支会被合并入master，并且用版本号打上标签。另外，发布分支上的改动还应该合并入develop分支——在发布周期内，develop分支仍然在被使用（一些开发者会把其他功能集成到develop分支）。
使用专门的一个分支来为发布做准备的好处是，在一个团队忙于当前的发布的同时，另一个团队可以继续为接下来的一次发布开发新功能。这也有助于清晰表明开发的状态，比如说，团队在汇报状态时可以轻松使用这样的措辞，“这星期我们要为发布4.0版本做准备。”从代码仓库的结构上也能直接反映出来。常用的一些措辞还有：基于develop新建分支，合并入master；命名规则为：release-或release/
-
用于维护的分支
图5
发布后的维护工作或者紧急问题的快速修复也需要使用一个独立的分支。这是唯一一种可以直接基于master创建的分支。一旦问题被修复了，所做的改动应该被合并入master和develop分支（或者用于当前发布的分支）。在这之后，master上还要使用更新的版本号打好标签。
这种为解决紧急问题专设的绿色通道，让团队不必打乱当前的工作流程，也不必等待下一次的产品发布周期。你可以把用于维护的分支看成是依附于master的一种特别的发布分支。
二. Gitflow模拟
下面的例子将演示Gitflow流程如何被用来管理一次产品发布。假设你已经创建好了一个中央仓库。
-
创建develop分支
图6
第一步是给默认的master配备一个develop分支。一种简单的做法是：让一个开发者在本地建立一个空的develop分支，然后把它推送到服务器。
git branch develop
git push -u origin develop
develop分支将包含项目的所有历史，而master会是一个缩减版本。现在，其他开发者应该克隆（clone）中央仓库，并且为develop创建一个追踪分支。
git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop
到现在，所有人都把包含有完整历史的分支（develop）在本地配置好了。
-
小马和小明开始开发新功能
图7
我们的故事从小马和小明要分别开发新功能开始。他们俩各自建立了自己的分支。注意，他们在创建分支时，父分支不能选择master，而要选择develop。
git checkout -b some-feature develop
他们俩都在自己的功能开发分支上开展工作。通常就是这种Git三部曲：edit，stage，commit：
git status
git add
git commit
-
小马把她的功能开发好了
图8
在提交过几次代码之后，小马觉得她的功能做完了。如果她所在的团队使用“拉拽请求”，此刻便是一个合适的时机——她可以提出一个将她所完成的功能合并入develop分支的请求。要不然，她可以自行将她的代码合并入本地的develop分支，然后再推送到中央仓库，像这样：
git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature
第一条命令确保了本地的develop分支拥有最新的代码——这一步必须在将功能代码合并之前做！注意，新开发的功能代码永远不能直接合并入master。必要时，还需要解决在代码合并过程中的冲突。
-
小马开始准备一次发布
图9
尽管小明还在忙着开发他的功能，小马却可以开始准备这个项目的第一次正式发布了。类似于功能开发，她使用了一个新的分支来做产品发布的准备工作。在这一步，发布的版本号也最初确定下来。
git checkout -b release-0.1 develop
这个分支专门用于发布前的准备，包括一些清理工作、全面的测试、文档的更新以及任何其他的准备工作。它与用于功能开发的分支相似，不同之处在于它是专为产品发布服务的。
一旦小马创建了这个分支并把它推向中央仓库，这次产品发布包含的功能也就固定下来了。任何还处于开发状态的功能只能等待下一个发布周期。
-
小马完成了发布
图10
一切准备就绪之后，小马就要把发布分支合并入master和develop分支，然后再将发布分支删除。注意，往develop分支的合并是很重要的，因为开发人员可能在发布分支上修复了一些关键的问题，而这些修复对于正在开发中的新功能是有益的。再次提醒一下，如果小马所在的团队强调代码评审（Code Review），此时非常适合提出这样的请求。
git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1
发布分支扮演的角色是功能开发（develop）与官方发布（master）之间的一个缓冲。无论什么时候你把一些东西合并入master，你都应该随即打上合适的标签。
git tag -a 0.1 -m"Initial public release" master
git push --tags
Git支持钩子（hook）的功能，也就是说，在代码仓库里某些特定的事件发生的时候，可以执行一些预定义的脚本。因此，一种可行的做法是：在服务器端配置一个钩子，当你把master推送到中央仓库或者推送标签时，Git服务器能为产品发布进行一次自动的构建。
-
用户发现了一个bug
图11
当一次发布完成之后，小马便回去与小明一起开发其他功能了。突然，某个用户提出抱怨说当前发布的产品里有一个bug。为了解决这个问题，小马（或者小明）基于master创建了一个用于维护的分支。她在这个分支上修复了那个bug，然后把改动的代码直接合并入master。
git checkout -b issue-#001 master
\# Fix the bug
git checkout master
git merge issue-#001
git push
跟用于发布的分支一样，在维护分支上的改动也需要合并入develop分支，这一点是很重要的！因此，小马务必不能忘了这一步。随后，她就可以将维护分支删除。
git checkout develop
git merge issue-#001
git push
git branch -d issue-#001
三. Gitflow结合SourceTree实践
- 创建本地仓库+远程仓库
此处略过
- 打开该仓库SourceTree控制界面
-
添加完成之后点击该按钮
图13
注意： 此处是配置，开发分支，发布分支名称，以及开发功能分支前缀，发布分支前缀，热修复分支前缀，以及版本号前缀。建议使用默认的形式。
- 初始化完成
此处会多出develop与master分支
- 开发功能模块
点击gitflow图标，new一个feature分支，然后输入当前要做的模块名称。
注意：此处最好在最新的develop分支上，进行创建feature，这样确保更少的冲突。
为该feature分支起一个名字
完成之后，可见当前分支的情况。
- 完成功能模块
完成开发之后，先commit到本地的feature分支上。然后点击gitflow按钮
注意：首先查看develop分支有没有其他人提交的记录，如果有需要pull下来的，先切回到develop分支先pull下来。然后切回到feature分支下。进行finish current操作。
注意：一般的开发完成之后，选择删除当前的feature分支，因为此处的分支为本地分支，你也可以选择保留当前feature分支，选择OK之后，会将当前的feature分支的内容合并到本地的develop分支上。
如果需要推送到origin，即可以推送到origin对应的分支上。
- 进行发布
点击gitflow按钮，然后选择new release
输入需要发布的版本号，此处输入的会将成为版本Tag信息。
然后将项目中需要改版本的号的文件进行相对应的提交和修改。完成之后commit到当前的release分支上。
- 完成发布
版本配置文件修改完成之后，进行合并，点击gitflow按钮，出现了，然后点击Finish Current。
注意：此处输入的信息，是对当前的Tag定制的提交信息。
点击完后后，会将当前的release分支合并到develop，master分支，是否要推倒origin，由coder自己决定。
这要做的好处是，master分支上的每个节点，都是一个版本。
方便查阅。
注意：此处发布时，需要team中，负责发布的coder去操作，避免多人发布，造成版本号，Tag混乱。
- 开始热修复
如果版本发出后，出现了一个bug，需要紧急的去修改，则需要使用new一个 hotfix，去进行开发。
注意：Hotfix分支是在最新节点的master分支上创建的，此处填入的hotfix的版本号。
- 完成热修复
完成Bug修复代码工作之后，提交到当前的本地hotfix分支上，完后进行finish 当前的hotfix分支，此处操作与release相同。
完成之后，会自动合并到本地的master，develop分支上，至于是否要push到origin由Coder自行决定。
四. 总结
team之间，使用Gitflow，进行开发辅助的分支管理，一定情况的减少了冲突发生的可能，但是此处在项目初期，项目结构发生变化较大的时候，冲突的可能会很大。此处建议尽可能在在项目搭建完成之后，进行team开发过程。使用Gitflow在开发功能模块，以及组件库方面，起到了很大的作用。确保了master分支每个节点都有Tag版本号，每个节点都是一个独立的版本。配合CI，可以读取到，master分支提交的节点数，Tag可以作为当前版本的版本号，可配置机器并且完成自动化发布的工作，提高工作效率。
五. 文献参考：
原文链接
Gitflow工作流程