[GIT] Git 工作流程(Git flow, Github flow flow, Git lab flow)
reference : http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
Git 作为一个源码管理系统,不可避免涉及到多人协作。
协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。"工作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。
本文介绍三种广泛使用的工作流程:
- Git flow
- Github flow
- Gitlab flow
如果你对Git还不是很熟悉,可以先阅读下面的文章。
一、功能驱动
本文的三种工作流程,有一个共同点:都采用"功能驱动式开发"(Feature-driven development,简称FDD)。
它指的是,需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(hotfix branch)。完成开发后,该分支就合并到主分支,然后被删除。
二、Git flow
最早诞生、并得到广泛采用的一种工作流程,就是Git flow 。
2.1 特点
它最主要的特点有两个。
首先,项目存在两个长期分支。
- 主分支
master
- 开发分支
develop
前者用于存放对外发布的版本,任何时候在这个分支拿到的,都是稳定的分布版;后者用于日常开发,存放最新的开发版。
其次,项目存在三种短期分支。
- 功能分支(feature branch)
- 补丁分支(hotfix branch)
- 预发分支(release branch)
一旦完成开发,它们就会被合并进develop
或master
,然后被删除。
Git flow 的详细介绍,请阅读我翻译的中文版《Git 分支管理策略》。
2.2 评价
Git flow的优点是清晰可控,缺点是相对复杂,需要同时维护两个长期分支。大多数工具都将master
当作默认分支,可是开发是在develop
分支进行的,这导致经常要切换分支,非常烦人。
更大问题在于,这个模式是基于"版本发布"的,目标是一段时间以后产出一个新版本。但是,很多网站项目是"持续发布",代码一有变动,就部署一次。这时,master
分支和develop
分支的差别不大,没必要维护两个长期分支。
三、Github flow
Github flow 是Git flow的简化版,专门配合"持续发布"。它是 Github.com 使用的工作流程。
3.1 流程
它只有一个长期分支,就是master
,因此用起来非常简单。
官方推荐的流程如下。
第一步:根据需求,从
master
拉出新分支,不区分功能分支或补丁分支。第二步:新分支开发完成后,或者需要讨论的时候,就向
master
发起一个pull request(简称PR)。第三步:Pull Request既是一个通知,让别人注意到你的请求,又是一种对话机制,大家一起评审和讨论你的代码。对话过程中,你还可以不断提交代码。
第四步:你的Pull Request被接受,合并进
master
,重新部署后,原来你拉出来的那个分支就被删除。(先部署再合并也可。)
3.2 评价
Github flow 的最大优点就是简单,对于"持续发布"的产品,可以说是最合适的流程。
问题在于它的假设:master
分支的更新与产品的发布是一致的。也就是说,master
分支的最新代码,默认就是当前的线上代码。
可是,有些时候并非如此,代码合并进入master
分支,并不代表它就能立刻发布。比如,苹果商店的APP提交审核以后,等一段时间才能上架。这时,如果还有新的代码提交,master
分支就会与刚发布的版本不一致。另一个例子是,有些公司有发布窗口,只有指定时间才能发布,这也会导致线上版本落后于master
分支。
上面这种情况,只有master
一个主分支就不够用了。通常,你不得不在master
分支以外,另外新建一个production
分支跟踪线上版本。
四、Gitlab flow
Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点,既有适应不同开发环境的弹性,又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。
4.1 上游优先
Gitlab flow 的最大原则叫做"上游优先"(upsteam first),即只存在一个主分支master
,它是所有其他分支的"上游"。只有上游分支采纳的代码变化,才能应用到其他分支。
Chromium项目就是一个例子,它明确规定,上游分支依次为:
- Linus Torvalds的分支
- 子系统(比如netdev)的分支
- 设备厂商(比如三星)的分支
4.2 持续发布
Gitlab flow 分成两种情况,适应不同的开发流程。
对于"持续发布"的项目,它建议在master
分支以外,再建立不同的环境分支。比如,"开发环境"的分支是master
,"预发环境"的分支是pre-production
,"生产环境"的分支是production
。
开发分支是预发分支的"上游",预发分支又是生产分支的"上游"。代码的变化,必须由"上游"向"下游"发展。比如,生产环境出现了bug,这时就要新建一个功能分支,先把它合并到master
,确认没有问题,再cherry-pick
到pre-production
,这一步也没有问题,才进入production
。
只有紧急情况,才允许跳过上游,直接合并到下游分支。
4.3 版本发布
对于"版本发布"的项目,建议的做法是每一个稳定版本,都要从master
分支拉出一个分支,比如2-3-stable
、2-4-stable
等等。
以后,只有修补bug,才允许将代码合并到这些分支,并且此时要更新小版本号。
五、一些小技巧
5.1 Pull Request
功能分支合并进master
分支,必须通过Pull Request(Gitlab里面叫做 Merge Request)。
前面说过,Pull Request本质是一种对话机制,你可以在提交的时候,@
相关人员或团队,引起他们的注意。
5.2 Protected branch
master
分支应该受到保护,不是每个人都可以修改这个分支,以及拥有审批 Pull Request 的权力。
Github 和 Gitlab 都提供"保护分支"(Protected branch)这个功能。
5.3 Issue
Issue 用于 Bug追踪和需求管理。建议先新建 Issue,再新建对应的功能分支。功能分支总是为了解决一个或多个 Issue。
功能分支的名称,可以与issue的名字保持一致,并且以issue的编号起首,比如"15-require-a-password-to-change-it"。
开发完成后,在提交说明里面,可以写上"fixes #14"或者"closes #67"。Github规定,只要commit message里面有下面这些动词 + 编号,就会关闭对应的issue。
- close
- closes
- closed
- fix
- fixes
- fixed
- resolve
- resolves
- resolved
这种方式还可以一次关闭多个issue,或者关闭其他代码库的issue,格式是username/repository#issue_number
。
Pull Request被接受以后,issue关闭,原始分支就应该删除。如果以后该issue重新打开,新分支可以复用原来的名字。
5.4 Merge节点
Git有两种合并:一种是"直进式合并"(fast forward),不生成单独的合并节点;另一种是"非直进式合并"(none fast-forword),会生成单独节点。
前者不利于保持commit信息的清晰,也不利于以后的回滚,建议总是采用后者(即使用--no-ff
参数)。只要发生合并,就要有一个单独的合并节点。
5.5 Squash 多个commit
为了便于他人阅读你的提交,也便于cherry-pick
或撤销代码变化,在发起Pull Request之前,应该把多个commit合并成一个。(前提是,该分支只有你一个人开发,且没有跟master
合并过。)
这可以采用rebase
命令附带的squash
操作,具体方法请参考我写的《Git 使用规范流程》。
[GIT] Git 工作流程(Git flow, Github flow flow, Git lab flow)的更多相关文章
- 【Git项目管理】分布式 Git - 分布式工作流程
分布式 Git - 分布式工作流程 你现在拥有了一个远程 Git 版本库,能为所有开发者共享代码提供服务,在一个本地工作流程下,你也已经熟悉了基本 Git 命令.你现在可以学习如何利用 Git 提供的 ...
- git教程——工作流程
Git 工作流程 本章节我们将为大家介绍 Git 的工作流程. 一般工作流程如下: 克隆 Git 资源作为工作目录. 在克隆的资源上添加或修改文件. 如果其他人修改了,你可以更新资源. 在提交前查看修 ...
- Git的工作流程
git的工作流程为: 克隆Git资源作为工作目录 在克隆的资源上添加或者修改文件 如果别人修改了,你可以更新资源 在提交前查看修改 提交修改 在修改完成后,如果发现错误,可以撤回提交并再次修改并提交 ...
- 4. Git基本工作流程
4. Git基本工作流程 Git工作区域 向仓库中添加文件流程
- Subversion/Git/ReviewBoard工作流程
根据My (work)Git Workflow进行修改,在 Windows下进行测试,http://mojodna.net/2009/02/24/my-work-git-workflow.html 目 ...
- 基于git的工作流程
本文针对的是追求极致.快速的产品响应团队的.以下的观点和内容都是围绕这个主题,暂时不涉及个人学习和团队学习. 在说工作流程之间,想说一下我们平常工作中遇到的一些困惑或者说现象 在一个团队里,同时有好多 ...
- git的工作流程(分支合并)
git支持很多种工作流程,我们采用的一般是这样,远程创建一个主分支,本地每人创建功能分支,日常工作流程如下: 去自己的工作分支$ git checkout work 工作.... 提交工作分支的修改$ ...
- 理解Git的工作流程(转)
英文原文:Understanding the Git Workflow 如果你不理解Git的设计动机,那你就会处处碰壁.知道足够多的命令和参数后,你就会强行让Git按你想的来工作,而不是按Git自己的 ...
- 1.Git起步-Git的三种状态以及三种工作区域、CVCS与DVCS的区别、Git基本工作流程
1.Git基础 版本控制系统是一种用于记录一个或多个文件内容变化,以便将来查阅恢复特定版本修订情况的系统. Git是一种分布式版本控制系统(Distributed Version Control Sy ...
- Git分布式工作流程
Git官网给出了三种分布式工作流程: 集中式工作流程 集成管理者工作流 司令官与副官工作流 这里以私有gitserver服务器上的git-test项目为例,简单说明集中式工作流程. 基于分支的开发策略 ...
随机推荐
- 数据迁移之Sqoop
一 简介 Apache Sqoop(TM)是一种用于在Apache Hadoop和结构化数据存储(如关系数据库)之间高效传输批量数据的工具 . 官方下载地址:http://www.apache.org ...
- HTML5 Canvas游戏开发(三)lufylegend开源库件(上)
lufylegend可以解决HTML5开发游戏中会遇到的一些问题: 1.各种浏览器对于JavaScript和HTML的解析是不一致的. 2.手机浏览器和PC浏览器的区别. 3.JavaScript并非 ...
- 有关FPGA
在FPGA发展历史上,前后共有过超过50家厂商,在国外目前剩下不到10家,除赛灵思和ALTERA两家持续不断地军备竞赛,其它的都有着各自固守的市场定位.即使是有新进入者,例如受英特尔新工艺支 ...
- Matlab 也很强大!
一.实时编辑器 所创建的脚本不仅可以捕获代码,还可以讲述与人分享的故事.自动化的上下文提示可让您在编程时快速推进,并且将结果与可视化内容和您的代码一起显示. 一般以 .mlx 为后缀. 二.App D ...
- HDU - 1716 排列2 水题
排列2 Time Limit: 1000/1000 MS (Java/Others) Memory Limit: 32768/32768 K (Java/Others) Total Submis ...
- CodeForces 140C New Year Snowmen(堆)
题面 CodeForces 题解 因为要保证两两不同,所以不能单纯的开堆来维护,堆维护一个二元组,个数为第一关键字,编号为第二关键字,对于一个相同的颜色,统计一下这个颜色的个数再用堆来维护就好了. # ...
- 【SQL】182. Duplicate Emails
Write a SQL query to find all duplicate emails in a table named Person. +----+---------+ | Id | Emai ...
- 支撑大规模公有云的Kubernetes改进与优化 (1)
Kubernetes是设计用来实施私有容器云的,然而容器作为公有云,同样需要一个管理平台,在Swarm,Mesos,Kubernetes中,基于Kubernetes已经逐渐成为容器编排的最热最主流的平 ...
- Linux内核中断处理机制
<什么是中断> 计算停下当前处理任务,并保存现场,转而去处理其他是任务,当完成任务后再回到原来的任务中去. <中断的分类> a:软中断 软中断时执行中断指令产生的,软中 ...
- django使用admin
1.在应用下的admin.py添加 #!/usr/bin/python # coding:utf-8 from django.contrib import admin from .models imp ...