团队项目协作过程中，需建立一套统一的版本控制工作流。版本控制工作流的标准化，是立方工作室数据组“作业流程化”的内容之一。
什么是git-flow?
git-flow 其实是根据一套项目分支管理原则而开发的git 扩展命令。git-flow 并不是新东西，它建立在原来的 git 之上。实际上，git-flow 就是通过建立通用性的分支管理规范，减少协作过程中的不一致和冲突问题，显著提高了软件项目开发协作效率。这种通用性的解决方案，让开发者在工作流程上达成共识，降低项目管理难度和流程损耗带来的成本，让开发者们专注于编写代码。
安装 git-flow
MacOS X 下配置好 brew 可以直接使用brew 安装。
$ brew install git-flow-avh
Windows 下可以基于VSCode 插件实现，也可以通过配置 GitHub for Windows 实现。具体查看文档：https://github.com/petervanderdoes/gitflow-avh/wiki/Installing-on-Windows
Linux 下，Ubuntu 可以直接通过包管理工具安装：
$ sudo apt-get install git-flow
其他Linux发行版则可以使用手动安装：
$ wget --no-check-certificate -q https://raw.githubusercontent.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh && sudo bash gitflow-installer.sh install develop; rm gitflow-installer.sh
git-flow 分支
前面提到git-flow 不过就是分支管理规范。git-flow 包括一些关键分支概念：
两个主分支，或者长期分支，存活在项目整个生命周期中。
- master 用来存放产品代码，不能直接提交改动到该分支。
- develop 进行任何新开发的基础分支，同时汇集了所有已经完成的功能，等待被整合到master 分支中。
支持性分支，临时分支，根据需要来创建，完成任务之后就会被删除。
- feature 进行新功能开发的分支，往往以
feature/作为前缀 - release 发行分支，基于develop 分支，以
release/加版本号命名 - hotfix 对发行后的版本的程序问题进行修复，基于master 分支，以
hotfix/作为前缀
（图片来自于：https://nvie.com/posts/a-successful-git-branching-model/）
如果我们要以该分支规则进行版本控制，需要写很多命令进行操作。如果我们要进行开发，需要在master 之外创建 develop 分支。然后新建 feature 分支进行开发。开发完成之后，需要合并到 develop 分支。合并完成之后，删除feature 分支。此时切换到了 develop 分支。如果功能开发成熟，即将发版，需要基于 develop 分支创建 release 分支。release 分支将合并至 master 分支，然后被删除。对发行版进行测试后，如果发现问题，需要在基于 master 分支创建 hotfix 分支对代码进行修复。修复完成后，将 hotfix 合并到 master 分支，并且删除 hotfix 分支。
进行一系列的命令操作有点儿麻烦，所以程序员们针对git-flow开发了一套命令行工具来方便我们更方便地进行以上一系列操作。当然，并不止于命令行工具，一般常见的开发工具都集成或者可被配置标准的 git-flow 工具。所以，无论你用 VSCode, 还是 Emacs, 甚至就喜欢原生的终端环境，你都可以方便使用 git-flow 工作流进行项目开发。
git-flow 适合什么场景？
git-flow 诞生的应用场景是多人项目开发协作的版本控制和项目管理。虽然如此，你个人的项目开发也可以遵循该流程。只要你的项目涉及到功能迭代，那么就能够在使用 git-flow 中获益。
如果你仅仅是对配置文件，或者文档进行版本控制，那么并不必使用该工作流。你可以使用更简便的分支管理方案实现更高效的版本控制。
git-flow 只是一种广受欢迎的版本控制工作流，实际上 git 最佳实践还包括了很多其他方面。在工作流上养成良好的习惯，就是在延长生命。
俗话说的好，“life is short, we use git conventions!”
详细学习资料：
- 作者：◎lixiang
- 时间：2019-03-07 09:42:21
若有收获，就点个赞吧
0 人点赞
