Gitflow Workflow

什么是 Gitflow 工作流？

Gitflow工作流是以Git作为源代码管理工具的团队的一种管理，开发，维护，发布的工作流程，它为项目的发布维护等工作定义了严谨的分支管理模型，同时也为大型项目提供了健壮的管理框架。
Gitflow工作流并不会创造新的Git概念和命令，相反，Gitflow工作流为每个指定的分支定义严格的功能角色，定义每个分支负责明确的工作任务，指定其在适当的时候进行适当的反应。另外，Gitflow工作流将会使用独立分支负责维护，开发，发布等工作。当然我们仍然需要使用如pull requests等工作方式来进行团队协作。

Gitflow工作流是怎么工作的

Gitflow工作流仍然使用中心仓库作为开发团队信息交流中心，和其他的Git工作流程一样，开发人员使用本地仓库进行工作，然后推送提交工作到中心仓库，唯一的区别就是Gitflow工作流的分支组织结构不一样。

Main Branch

仓库启动时，需要指定一个主分支 master，分支如下：

主分支将一直存在于这个仓库，直到项目结束或者仓库删除。

Develop Branch

和使用单一的master分支不一样的是，Gitflow工作流将使用两个分支(master分支和dev分支)来记录整个项目的履历。master分支用于记录项目的官方发布履历，而dev分支作为功能(feature)分支聚集中心，同时也约定master分支将使用版本号来进行标记，以备后续的查询和引用，这两个分支的关系如下：

Gitflow工作流的后续工作都将围绕这两个分支展开。
而且这两个分支将不会删除，一直存在

Feature Bugfix Branches

严格意义上讲，每一个新的开发工作内容都应该在独立的分支中完成，这些工作在完成后都应该被推送提交到中心仓库以备持久，备份以及相互协作。但是需要注意的是，feature/bugfix分支不能从master分支继承，应当从dev分支继承，当一个开发工作结束后，这些完成的工作都应该推送提交到dev分支，切记，feature/bugfix分支不能直接和master分支进行交互，到这一步，代码分支结构如下：

注意：此处的 feature/bugfix 分支都是从 dev 分支开启的，并且只能合并到 dev

bugfix 分支不止可以在 dev 开发时使用，也可以在 release 即将发布时使用。主要用于场景是，功能开发中，前一个功能出现问题，这时可以启动一个 bugfix 来进行修改；同样的在 release 即将发布之前，如果测试出来问题，也可以启动一个 bugfix 来进行修改。

注意：bugfix 严格情况下，只能在 dev 和 release 分支上启动

Release Branches

当我们要进行正式发布的时候，我们需要创建独立的release分支，加入release分支后代码分支结构如下：

当develop分支包含了足够适合发布的功能或者达到了发布计划日期后，将会启动发布流程，我们前面也提到Gitflow工作流的每项工作都基于独立的分支进行，因此我们将从dev分支衍生(fork)出独立的release分支，从创建新的release分支开始，我们就进入了新的发布周期，因此这个release分支将不再接受新的功能的加入，但是严重bug修改除外，后续的文档更新，以及其他任何和这次发布相关的工作都应该在这个release分支上进行，一旦发布工作准备完成，并确定要上市的时候，这个release分支需要合并回master分支，并且使用版本号为master分支进行标记，同时由于release分支可能存在bug的修改等相关改动，因此这些修改也需要合并到dev分支，以备这些修改能正确反映到后续版本的发布中。

使用独立的发布分支可以让发布人员进行发布的同时，也不影响开发人员进行后续版本的开发，这样也就让开发各个周期定义变得更清晰，当然，我们对release分支有些约定

1. release分支必须从dev分支继承
2. release分支在完成发布工作后需要合并到master分支，同时按需要合并回dev分支
3. release分支命名约定为：release/{version}
4. release合并完成后可根据自己需求选择保留或者删除

Hotfix Branches

hotfix(maintenance)分支用于快速修正线上产品出现的严重问题，hotfix分支是唯一直接从master分支衍生(fork)的分支，当hotfix的工作完成后，这些工作应该合并回master分支和dev分支，如果当前有发布工作正在执行，这些工作同时需要合并到当前的release分支，同时master分支需要使用更新版本号进行标记，代码分支结构如下：

使用独立的hotfix分支，可以让开发团队可以快速的定位紧急的问题，但同时也不会打断当前开发工作的流程，也不需要再等到下班版本的更新。
实际上可以把hotfix分支看做一个直接和master分支进行交互的临时release分支。

总结

以上就是一个项目的完整的开发git工作流，主要针对于开发人员的代码开发和发布。