Git超实用管理框架——Git Flow、GitHub Flow、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)常用分支
分支名称 | 分支功能 | 分支特性 | 提交规则 | 备注 |
master | 产品的功能全部实现后最终在master分支对外发布 | 只读分支,只能从其他分支(release/hotfix)合并,不能在此分支修改 | release合并到master , 或hotfix合并到master | 所有在master分支的推送应该打标签做记录,方便追溯 |
develop | 基于master分支克隆,包含所有要发布到下一个release的代码 | 只读分支,只能从其他分支合并。 | Feature功能分支完成合并到develop(不推送); develop拉取release分支,提测; release/hotfix分支上线完毕,合并到develop并推送 |
|
feature | 基于develop分支克隆,主要用于新需求新功能的开发 | 功能开发完毕后合并到develop分支(未正式发布之前不推送到远程*仓库) | feature分支可同时存在多个,用于团队中多个功能同时开发,属于临时分支,功能完成后可选删除 | |
release | 基于feature分支合并到develop之后,从develop分支克隆,主要用于提交给测试人员进行功能测试 | 属于临时分支,功能上线后可选删除 | 测试过程中发现的BUG在本分支进行修复 , 修复完成上线后合并到develop/master分支并推送(完成功能) , 打Tag | |
hotfix | 基于master分支克隆,主要用于对线上版本进行bug修复 | 属于临时分支,补丁修复上线后可选删除 | 修复完毕后合并到develop/master分支并推送,打Tag | 所有hotfix分支的修改会进入到下一个release |
(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