Git flow

A successful Git branching model

与基于主干的开发（trunk-based development）相比，Gitflow拥有大量生存周期更长的分支和更大的提交。在这个模型下，开发人员创建一个特性分支，并直到特性完成才将其合并到主干分支，这个周期可能延续很长时间段。这些长期存在的特性分支需要更多的协作来完成合并，并且有更高的偏离主干分支的风险。它们还可能引入相互冲突的更新。

Gitflow可以用于有固定发布周期的项目，也可以用于DevOps持续交付的最佳实践。该工作流没有添加任何超出特性分支工作流所需的新概念或命令。相反，它将非常具体的角色分配给不同的分支，并定义它们应该如何以及何时交互。除了特性分支之外，它还使用单独的分支来准备、维护和记录版本。当然，您还可以利用特性分支工作流的所有好处：拉取请求、功能隔离实验和更高效的协作。

1. 开发（Develop） 和 主（main） 分支

这种工作流模式使用两个分支来记录项目的历史，而不是单一的主（main）分支。主分支存储官方发布历史，开发（develop）分支作为功能的集成分支。用版本号（tag）标记主分支中的所有提交也很方便。

2. 特性（Feature）分支

每个新特性（feature）都应该驻留在自己的分支中，可以推送到中央存储库进行备份/协作。但是，特性分支使用develop作为它们的父分支，而不是从main分支分支出去。当一个特性完成时，它会被合并回开发分支中。特性不应该直接与main交互。

3. 发布（Release）分支

一旦develop获得了发布所需的足够特性(或者预定的发布日期即将到来)，就可以从develop中分离出一个release分支。创建这个分支开启下一个发布周期，所以这个点之后，不能添加任何新特性到这个分支了，只有对bug的修复、文档生成和其他面向发布的任务可以添加到这个分支。一旦发布完成，发布分支就会合并到main中，并tag一个版本号。此外，应该将它合并回开发中，因为开发分支很有可能在发布分支打出来后，就已经进行了。

4. 热修复（Hotfix）分支

维护或“热修复”分支用于快速修补生产版本。热修复分支很像发布分支和特性分支，除了它们是基于main而不是develop。这是唯一应该直接从主分支分叉的分支。一旦修复完成，就应该将其合并到main和develop(或当前发布分支)中，并且main应该标记为更新的版本号。

##### 总结

这里我们讨论了Gitflow工作流。Gitflow是你和你的团队可以使用的众多Git工作流风格之一。

###### Gitflow的一些关键要点是:

* 工作流对于基于发布的软件工作流来说非常棒。

* Gitflow为生产提供了一个专门的修复通道。

###### Gitflow的总体流程是:

1. 从main创建一个develop分支

2. 从develop创建release分支

3. 从develop创建feature分支

4. 当一个feature完成时，它被合并到develop分支中

5. release分支完成后，将其合并为develop分支和main分支

6. 如果发现main中的问题，则从main创建hotfix分支

7. 一旦修复完成，它将合并为develop和main

Gitflow workflow

Git Flow

Introducing GitFlow

Using git-flow to automate your git branching workflow