Gitflow工作流示例
前言
本文演示了如何用Gitflow来管理单个发布循环。
初始化中央仓库
这时，Git会为你默认创建一个master分支，将你的最初的项目代码提交到master分支上。
创建开发分支
从master创建一个develop分支，并将其push到服务器上。并让团队中每个成员都建立该分支的本地拷贝。develop分支将会包含项目的全部历史提交，而master分支可能只包含部分历史提交。
开始开发新功能
Jack需要基于develop分支拉取feature1分支，并在该分支上面进行新功能的开发。
完成新功能开发
Jack提交了所有代码到分支feature1上之后，将feature1分支合并到develop分支，解决冲突并推送到中央仓库。这里需要在合并前确保本地的develop分支是最新的。
发布新功能
Jack确定了发布的版本号为0.1，并且从develop拉了一个发布分支release-0.1，在发布过程中产生的问题都会提交到这个分支上，发布前执行测试和创建release note也都会基于这个分支来做。这里做到了所谓的发布前的代码冻结的作用。
完成发布
Jack完成了0.1版本的发布，并且把release-0.1分支合并到master分支上，同时在master分支上提交了0.1版本的tag。并把master分支合并到develop分支上。
这时，一个新功能的开发和一个新版本的发布已经完成。下面来看一下hotfix的流程。
发现bug并进行hotfix
Jack从master拉取了一个hotfix-issue-001分支，并且对issue-001进行修复。
发布hotfix
Jack发布了hotfix-issue-001分支，并将其合并回master分支。然后再将master分支与develop分支进行合并。
这时，一个hotfix的发布已经完成。
上面所列举的Gitflow的用法只是使用过程中的某种特例，并不是所必须要遵守的规定。我们在使用Gitflow的过程中，需要大胆地对Gitflow的用法做取舍，以满足项目管理的健壮，完备和简洁。
后记
简化
这里提供一种简化Gitflow的思路，适用于小型开发团队。master分支与develop分支可以在同时开发的功能较少时进行简化，只使用master分支，略去develop分支。feature分支与release分支可以在开发人员较少时进行简化，只使用feature分支，略去release分支。
扩展
- 在并行开发的功能较多时，需要特别为发布计划和代码merge建立管理制度，以防止不同的功能之间冲突过多而花费大量时间。
- 在开发人员较多时，可以采用在feature分支的基础上在拉取类似于feature-jack的个人开发分支，以减少开发过程中的冲突。
- 针对有较为严格code review规定的团队，可以采用pull request来进行code review。
- 所有的团队都需要注意，定时清理不需要的分支。
- 所有的团队都需要注意，需要制定严格的分支名称的规则。