git flow

目录

1.Git flow
2.Github flow
3.Gitlab flow

1.Git flow

git flow_第1张图片

主要特点

1.存在两个长期分支

主分支master
开发分支develop

master用于存放对外发布的版本,任何时候在这个分支拿到的,都是稳定的分布版;develop用于日常开发,存在最新的开发版。

2.存在三种短期分支

功能分支(feature branch)   
补丁分支(hotfix branch)  
预发分支(release branch)  

评价

Git flow的有点是清晰可控,缺点是相对复杂,需要同时维护两个长期分支。大多数工具都将master当做默认分支,可以开发是在develop分支进行的,这导致经常要切换分支。
这个模式是基于“版本发布”的,目标是一段时间以后产出一个新版本。但是很多网站项目是“持续发布”,代码一有变动,就部署一次,这时,master和develop分支的差别不大,没必要维护两个长期分支。

2.Github flow

Github flow是Git flow的简化版,专门配合“持续发布”。

主要特点

Github flow只要一个长期分支,就是master,因此用起来比较简单。
git flow_第2张图片
1.根据需求,从master拉出新分支,不区分功能分支或补丁分支。
2.新分支开发完成后,或者需要讨论的时候,就向master发起一个pull request
3.pull request的过程中,你可以不断提交代码。
4.你的pull request被接受,合并进master,重新部署后,原来拉出来的分支就被删除。

评价

Github flow的最大优点就是简单,对于“持续发布”的产品,可以说是最合适的流程。
问题在于它认为master分支的更新与产品的发布是一致的。master分支的最新代码,默认就是当前线上的代码。
可是,有时候并非如此,代码合并进入master分支,并不代表它就能立刻发布。比如,提交Apple的APP,审核需要一段时间才能上架,这时,如果还有新的代码提交,master分支就会与刚发布的版本不一致。

3.Gitlab flow

Gitlab flow是Git flow与Github flow的综合

主要特点

Gitlab flow的最大原则叫做“上游优先”,即只存在一个主分支master,它是所有其他分支的上游,只有上游分支采纳的代码变化,才能应用到其他的分支。

1、持续发布

git flow_第3张图片
对于”持续发布”的项目,它建议在master分支以外,再建立不同的环境分支。比如,”开发环境”的分支是master,”预发环境”的分支是pre-production,”生产环境”的分支是production。

开发分支是预发分支的”上游”,预发分支又是生产分支的”上游”。代码的变化,必须由”上游”向”下游”发展。比如,生产环境出现了bug,这时就要新建一个功能分支,先把它合并到master,确认没有问题,再cherry-pick到pre-production,这一步也没有问题,才进入production。
只有紧急情况,才允许跳过上游,直接合并到下游分支。

2、版本发布

git flow_第4张图片

对于”版本发布”的项目,建议的做法是每一个稳定版本,都要从master分支拉出一个分支,比如2-3-stable、2-4-stable等等。

以后,只有修补bug,才允许将代码合并到这些分支,并且此时要更新小版本号。

补充:Pull Request/ Merge Request

当要发起一个Pull Request,需要请求(Request)另一个开发者,来pull你仓库中的一个分支到他的仓库中。这需要提供4个信息(源仓库、源分支、目的仓库、目的分支),以发起Pull Request。

实际项目

我们项目中使用的是Gitlab flow,对master和develop开启权限,没有权限的开发者不能合并到develop分支上面,需要发起merge request请求。Gitlab flow对分支的管理比较严谨,所以整个流程会比较复杂。如果有新人加入开发,就可以通过控制他的权限来控制代码的质量。

而我们公司的另一个项目组使用的是Git flow,只维护master分支,所有的代码都自行合并到master上。这种方式比较适合少人开发,或者开发者都是项目主力的情况下,不需要进行review代码的这一步。提交合并代码的流程变得简单许多。不过这样,就需要所有的开发者对自己的bug负责,提交的代码如果影响到其他人的代码,也是不允许的。

建议是用sourceTree工具来处理代码的提交合并。

参考资料:

http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
https://lucamezzalira.com/2014/03/10/git-flow-vs-github-flow/
http://blog.jobbole.com/76867/
http://www.ituring.com.cn/article/56870

你可能感兴趣的:(git flow)