讲一下你认识的Gitflow

Gitflow Workflow

Gitflow是一个Git自带的Git工作流，它最初是一种用于管理Git分支的破坏性和新颖的策略。Gitflow已经开始流行于基于主干的工作流，它现在被认为是现代连续软件开发和DevOps实践的最佳实践。Gitflow在与CI/CD一起使用时也很有挑战性。这篇文章详细介绍了Gitflow的历史用途。

什么是GitFlow？

Giflow是另一种Git分支模型，它涉及到特征分支和多个主分支的使用。最早由文森特·德里森在nvie首次出版并广受欢迎。与传统的开发相比，Giflow拥有众多、寿命更长的分支和更大的提交。在此模型下，开发人员创建一个功能分支，并延迟将其合并到主干分支，直到功能完成。这些长期存在的功能分支需要更多的协作才能合并，并且偏离主干分支的风险更高。它们还可能引入冲突的更新。

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

准备开始

Gitflow实际上只是Git工作流的一个抽象概念。这意味着它决定了要设置什么样的分支以及如何将它们合并在一起。我们将在下面讨论分支的用途。git flow工具集是一个具有安装过程的实际命令行工具。git flow的安装过程非常简单。git flow的包可在多个操作系统上使用。在OSX系统上，可以执行brew install git flow。在windows上，您需要下载并安装git flow。安装git flow后，可以通过执行git flow init在项目中使用它。Git流是Git的包装器。git-flow-init命令是默认git-init命令的扩展，除了为您创建分支之外，不会更改存储库中的任何内容。

怎样去工作

Develop 和 master 分支

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

第一步是用一个开发分支来补充默认的master。一个简单的方法是让一个开发人员在本地创建一个空的开发分支，并将其推送到服务器：

git branch develop
git push -u origin develop

该分支将包含项目的完整历史记录，而master将包含一个摘要版本。现在，开发人员应该为其他开发人员创建一个克隆跟踪存储库。

使用git flow扩展库时，在现有repo上执行git flow init将创建开发分支：

$ git flow init


Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [main]
Branch name for "next release" development: [develop]


How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []


$ git branch
* develop
 master

Feature 分支

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

请注意，与“开发”分支相结合的功能分支出于所有目的都是功能分支工作流。但是，Gitflow工作流并没有就此停止。

release分支通常创建到最新的开发分支。

创建一个Feature分支

不使用GitFlow扩展：

git checkout develop
git checkout -b feature_branch

使用GitFlow扩展：

git flow feature start feature_branch

继续正常的使用你的git，他不影响你使用他

完成一个Feature分支

完成功能的开发工作后，下一步是将功能分支合并到develop中。

不适用GitFlow：

git checkout develop
git merge feature_branch

使用GitFlow：

git flow feature finish feature_branch

发布新的版本分支

一旦develope获得了足够的发布特性（或者预定的发布日期即将到来），您就可以从develope分支出一个发布分支。创建此分支将开始下一个发行周期，因此在此之后不能添加任何新功能，只有bug修复、文档生成和其他面向发行版的任务应包含在此分支中。一旦准备好发布，发布分支就会合并到main中，并用版本号进行标记。此外，应该将其合并回develope中，develope可能在发布启动后已经取得了进展。

使用一个专门的分支来准备发行版，可以让一个团队完善当前发行版，而另一个团队继续为下一个发行版开发功能。它还创建了定义良好的开发阶段（例如，很容易说，“本周我们正在准备4.0版”，并在存储库的结构中实际看到它）。

制作发布分支是另一个简单的分支操作。与功能分支一样，发布分支基于开发分支。可以使用以下方法创建新的发布分支。

不使用GitFlow：

git checkout develop
git checkout -b release/0.1.0

使用GitFlow：

$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'

一旦发布准备好发布，它将被合并到main和develop中，然后发布分支将被删除。重新合并到develop中是很重要的，因为关键更新可能已经添加到发布分支中，并且它们需要能够被新功能访问。如果您的组织强调代码审查，那么这将是请求拉取的理想场所。

要完成发布分支，请使用以下方法：

不使用GitFlow：

git checkout main
git merge release/0.1.0

使用GitFlow：

git flow release finish '0.1.0'

Hotfix分支

维护或“修补程序”分支用于快速修补生产版本。热修复分支与发布分支和功能分支非常相似，只是它们基于main而不是develope。这是唯一应该直接从干管分叉的分支。一旦修复完成，它应该合并到main和developer（或当前版本分支）中，并且main应该用更新的版本号进行标记。

拥有专门的bug修复开发线可以让您的团队解决问题，而不会中断工作流的其余部分或等待下一个发布周期。您可以将维护分支视为直接与main一起工作的临时发布分支。可以使用以下方法创建修补程序分支：

不使用GitFlow：

git checkout main
git checkout -b hotfix_branch

使用GitFlow：

$ git flow hotfix start hotfix_branch

与完成发布分支类似，热修复分支合并到main和developer中。

不使用GitFlow：

git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch

使用GitFlow：

$ git flow hotfix finish hotfix_branch