3.2 KiB
Gitflow工作流
这节介绍的Gitflow工作流借鉴自在nvie的Vincent Driessen。
Gitflow工作流定义了一个用于解决项目发布的严格分支模型。相应地也比功能分支工作流复杂几分，提供了管理大型项目的一个健壮的框架。
这个工作流没有比功能分支工作流有新的概念和命令。而是为不同的分支分配一个很明确的角色，并定义如何和什么时候分支要交互。
比起功能分支工作流，使用为做准备、维护和记录发布使用各自的分支。当然你也用上功能分支工作流所有的好处：Pull Requests、隔离实验性开发和更高效的协作。
🍺 工作方式
Gitflow工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并push到要中央仓库中。
历史分支
相对使用仅有一个master分支，本工作流使用2个分支记录项目的历史。master分支存储了正式发布的历史，而develop分支作为功能的集成分支。
这样也方便master分支上的所有提交分配一个版本号。
剩下要说明的问题围绕着这2个分支的区别展开。
功能分支
每个新功能属于一个自己的分支，这样可以push到中央仓库以备份和协作。
但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。功能应该从不直接到master分支交互。
注意，从含义和目的上来看，功能分支加上develop分支是功能分支工作流的用法。但Gitflow工作流没有在这里止步。
发布分支
一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上fork一个发布分支。
新建的分支用于开始下一轮的开发循环，之后新的功能不能再加到这个分支上，这个分支只应该做Bug修复、文档生成和其它面向发布任务。
一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。
另外，这些从新建发布分支以来的做的修改要合并回develop分支。
使用一个做准备分布的专门分支，使得一个团队可以在完善当前的发布版本，同时另一个团队继续开发下个版本的功能。 这也打造定义良好的开发阶段（比如，可以很轻松地说，『这周我们要做准备发布版本4.0』，并且在仓库的目录结构中可以真实地看到）。
一般的分支约定：
用于新建发布分支的分支: develop
用于合并的分支: master
分支命名: release-* or release/*
维护分支
