Git超实用管理框架——Git Flow、GitHub Flow、GitLab Flow工作流程详解_gitflow gitlab flow

之前一直在用git，但仅仅只是在自己的分支push和pull，用的也是GUI来提交，没有想那么多，可是突然成为一个管理者的时候发现git项目管理还是很重要的，然后自己之前也没有系统学习过。对于Git常用命令是个程序员都不用多说什么，大家肯定信手拈来，但对于技术团队，还是需要用较为规范的 Git操作流程，本篇也是相应学习总结。

Git最重要的概念就是分支（fork），而操作流程的复杂度也取决于分支的个数和提交的复杂度。最大而全的框架就是Git Flow了，分支较多，非常适用于版本发布的工作流程。但不太适合持续发布（代码部署非常频繁）的开发场景。所以GitHub Flow对Git Flow做了简化，并充分利用了GitHub 的Pull Request功能，是一个非常轻便的基于分支的工作流。它只维护一个长期分支master，其它的无论是做什么用途的分支都算临时分支，用完即删除。如此，无论何时发布master，其都是最新的内容。而GitLab Flow则是吸收了Git Flow和GitHub Flow的优点，遵循“上游优先”的策略，做到既简单容易操作，又能满足不同的工作流程。

 

一、Git Flow简介

（1）常用分支

（2）工作流程（步骤中仅列举部分相关命令）

1. 初始化项目为gitflow，默认创建master分支，然后从master拉取第一个develop分支：(git checkout develop; git pull)

2. 从develop拉取feature分支进行编码开发（多个开发人员拉取多个feature同时并行开发，互不影响）：(git flow feature)

3. feature分支完成后，合并到develop（不推送，feature功能完成还未提测，推送后会影响其他功能分支的开发）：(git push origin feature; git checkout develop; git merge feature)

合并feature到develop，可以选择删除当前feature，也可以不删除，但当前feature就不可更改了，必须从release分支继续编码修改

4. 从develop拉取release分支进行提测，提测过程中在release分支上修改bug：(git checkout develop; git pull; git flow release start '1.0.0')

5. release分支上线后，合并release分支到develop/master并推送：(git flow release finish '1.0.0')

合并之后，可选删除当前release分支，若不删除，则当前release不可修改，线上有问题也必须从master拉取hotfix分支进行修改

6. 上线之后若发现线上bug，从master拉取hotfix进行bug修改：(git fetch origin; git flow hotfix start '1.0.1' '1.0.0'; git push origin hotfix/1.0.1)

7. hotfix通过测试上线后，合并hotfix分支到develop/master并推送：(git push origin develop) (git checkout master; git push origin master; git push --tags)

合并之后，可选删除当前hotfix分支，若不删除，则当前hotfix不可修改，若补丁未修复，需要从master拉取新的hotfix继续进行修改

8. 当进行一个feature时，若develop分支有变动，如其他开发人员啊完成功能并上线，则需要将完成的功能合并到自己的分支上，即合并develop到当前feature分支

9. 当进行一个release分支时，若develop分支有变动，如其他开发人员完成功能并上线，则需要将完成的功能合并到自己分支上

即合并develop到当前release分支（因为当前release分支通过测试后会发布到线上，如果不合并最新的develop分支就会发生丢失代码的情况

更详细的Git Flow工作流程图如下：

 

二、GitHub Flow简介

1. 始终保持master主干分支为可发布、部署的状态(这样可以时刻被创建特性分支或者可以被部署)，不能在其上进行开发

2. 新特性、作业或修改bug，从主干分支创建新的本地分支（该分支应具有描述性的名称），若该分支已存在，应先git pull更新为远程仓库master主干分支的最新状态：（git branch -b feature master;）

3. 确认在本地环境中通过所有测试，此后便可修改新建的本地分支下内容(一般只修改一定小粒度的内容)并在该分支中进行提交(修改内容前一般需要先编写测试代码)：( git checkout master; git merge feature)

4. 在GitHub端的仓库中创建同名的分支，并push操作(即在该分支下创建远程分支)

5. 此外可通过Pull Request反馈、交流(整个过程可能多次被请求审查、重新修改等直到完成作业)。即开发结束后向master发送 Pull Request，Pull Request通过review之后合并到 master，并从master向正式环境发布；

6. 让其他开发者进行审查，待确认后再与master主干分支进行合并(事实上应现在本地测试通过)

7. 与master主干分支合并后即刻部署，而在部署到正式环境之前需要先通过测试(包自动化测试、持括测试代码编写、续集成等工具(部分部署工具: Capistrano、Mina、Fabric、Cinnamon、Webistrano、Strano等，持续集成IC: Jenkins、Travish CI等))

三、GitLab Flow简介

（1）持续发布使用说明

持续发布的场景要求我们随时都有最新的内容发布到生产，因此我们还是保留一个master长期分支，它作为其它任何分支的上游分支，然后再分别创建一个预发布分支pre-production和发布分支production：

git checkout -b pre-production master

git checkout -b production master

 

其中，预发布分支pre-production是用来检测master上的更新内容是否具有风险和Bug的，如果没有问题，则直接再合并到production上，进行发布即可。

git checkout pre-production

git merge master

 

git checkout production

git merge pre-production

 

如此，可以实现使用GitLab Flow来实现持续发布的工作流程。

 

（2）版本发布使用说明

每一个稳定的版本都单独作为一个分支存在，从master上拉取出来。以后只有master上的Bug修复才会被允许cherry-pick到这些单独的版本分支上，而对于master上的新内容是不采取合并操作的：

git checkout -b stable1 master

创建了稳定版本stable1分支后，master可以继续接受来自其它分支的合并内容，但这些内容和stable1分支没有关系，因为stable1分支是某个具体的版本，只包含固定的内容。只有那些发现了存在于stable1上的Bug，才会需要从master合并到stable1上。因为GitLab Flow遵循的上游优先策略，我们只有先合并到master上，才能再从master上合并到stable1上

git cherry-pick 提交号

 

如上，就可以实现使用GitLab Flow来实现版本发布的工作流程，大致示意图如下：

 

参考网址：

https://blog.csdn.net/xingbaozhen1210/article/details/81386269

https://www.jianshu.com/p/bf9218e8feb2

http://www.manongjc.com/detail/12-vvqiojvjfvansoy.html