1.1 简介
Gitflow.工作流定义了一个围绕项目发布的格分支模型。虽然比功能分支工作流复杂几分,但提供 了用于一个健壮的用于管理大型项目的框架。
Gitflow工作流没有用超出功能分支工作流概念和命令,而是为不同的分支分配一个很明确的角 色,并定义分支之间如何和什么时候进行交。除了使用功能分支,在做准备、维护和记录发布也使用各 自的分支。当然你可以用上功能分支工作所有的好处: Pull Requests、隔离实验性开发和更高效的协 作。
Gitflow.工作流仍然用中央仓库作为所有开者的交互中心。和其它的工作流一样,开发者在本地工 作并push分支到要中央仓库中。
1.2 分支定义
- develop：用于新建发布分支的分支,即所有需要上线的内容都必须在 develop分支,然后通过 develop分支创建上线分支.该分支上不允许有任何人直接提交
- master： 用于合并的分支,即分支上不允许有任何人直接提交,仅作为记录项目历 史、版本号使用和上线使用;
- feature:/[分支名]: 研发分支,即任务支,每一个 feature都必须是基于 develop分支创 建,并需要和 develop分支保持更新,且个分支只能做一个任务,禁止分支复用。
- release/[版本号]：预上线分支,基于 develop分支创建,分支名即是版本号信息;
- hotfix/[版本号]：热修复分支,唯一一个于 master创建的分支,分支名是版本号信息目前
1.3 历史分支
Gitflow使用两个分支来记录项目开发的历史，而不是使用单一的master分支。在Gitflow流程中，master只是用于保存官方的发布历史，而develop分支才是用于集成各种功能开发的分支。使用版本号为master上的所有提交打标签（tag）也很方便。
1.4 功能分支
每一个新功能的开发都应该各自使用独立的分支。为了备份或便于团队之间的合作，这种分支也可以被推送到中央仓库。但是，在创建新的功能开发分支时，父分支应该选择develop（而不是master）。当功能开发完成时，改动的代码应该被合并（merge）到develop分支。功能开发永远不应该直接牵扯到master。
1.5 发布分支
一旦develop分支积聚了足够多的新功能（或者预定的发布日期临近了），你可以基于develop分支建立一个用于产品发布的分支。这个分支的创建意味着一个发布周期的开始，也意味着本次发布不会再增加新的功能——在这个分支上只能修复bug，做一些文档工作或者跟发布相关的任务。在一切准备就绪的时候，这个分支会被合并入master，并且用版本号打上标签。另外，发布分支上的改动还应该合并入develop分支——在发布周期内，develop分支仍然在被使用（一些开发者会把其他功能集成到develop分支）。
使用专门的一个分支来为发布做准备的好处是，在一个团队忙于当前的发布的同时，另一个团队可以继续为接下来的一次发布开发新功能。这也有助于清晰表明开发的状态，比如说，团队在汇报状态时可以轻松使用这样的措辞，“这星期我们要为发布1.0版本做准备。”从代码仓库的结构上也能直接反映出来。
