Gitflow 工做流简介

Gitflow工做流简介

Gitflow工做流经过为功能开发、发布准备和项目维护分配独立的分支，让发布迭代过程更流畅。

Gitflow工做流定义了一个围绕项目发布的严格分支模型，它会相对复杂一点，但提供了用于一个健壮的用于管理大型项目的框架，很是适合用来管理大型项目的发布和维护。 贯穿整个开发周期，master和develop分支是一直存在的，master分支能够被视为稳定的分支， 而develop分支是相对稳定的分支，特性开发会在feature分支上进行，发布会在release分支上进行，而bug修复则会在hotfix分支上进行，这样也有效避免了不一样类型的开发工做在代码层级的耦合和干扰。

一、历史分支

Gitflow工做流使用2个分支来记录项目的历史。 master分支存储了正式发布的历史，而develop分支做为功能的集成分支。 这样也方便master分支上的全部提交分配一个版本号。

二、功能分支

每一个新功能位于一个本身的分支，这样能够push到中央仓库以备份和协做。 但功能分支不是从master分支上拉出新分支，而是使用develop分支做为父分支。 当新功能完成时，合并回develop分支。 新功能提交应该从不直接与master分支交互。

三、发布分支

一旦develop分支上有了作一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上checkout一个发布分支。 新建的分支用于开始发布循环，因此从这个时间点开始以后新的功能不能再加到这个分支上，这个分支只应该作Bug修复、文档生成和其它面向发布的任务。 一旦对外发布的工做都完成了， 发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些重新建发布分支以来的作的修改要合并回develop分支。使用一个用于发布准备的专门分支，使得一个团队能够在完善当前的发布版本的同时，另外一个团队能够继续开发下个版本的功能。

四、维护分支

维护分支或说是热修复（hotfix）分支用于快速给产品发布版本（production releases）打补丁， 这是惟一能够直接从master分支fork出来的分支。 修复完成，修改应该立刻合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。为Bug修复使用专门分支，让团队能够处理掉问题而不用打断其它工做或是等待下一个发布循环。

若是你没有认识到这个工做流颇有用，那多是由于你的开发工做尚未复杂到一个程度，一个必需要规避代码干扰、保证并行推动的程度。

参考资料

GitFlow 工做流