GitFlow

GitFlow

总则

-统一使用Git作为版本控制的主要工具。

-统一使用GitFlow流程管理控制版本。

提交的准则

1.除了源码相关的东西之外,其他build产生的东西(如:maven的target文件夹,.idea文件夹等),均不能提交进入源码仓库,添加到.gitignore文件中忽略掉。

2.撰写规范的提交说明。一份好的提交说明可以帮助协作者更轻松更有效地配合工作。

3.要严格按照我们指定的流程切换到指定分支,开发相应的功能。

分支简述

我们使用的分支流程:

[图片上传失败...(image-9693d8-1601368094316)]

主要分支简述

-天蓝色圆点所在的线为我们源码的主线(master)。

-天蓝色方形指向的节点就是每一个发布版本的标签(tag)。

-紫色圆点所在的线为主要分支线(develop)。

-橙色圆点所在的线为新功能开发分支线(feature)。

-绿色圆点所在的线为新版本发布线(release)。

-红色圆点所在的线为发布版本bug修复线(hotfix)。

主分支说明

代替原来的单个主线(master),我们使用两个分支来记录源码轨迹:

1.原来的master分支用来记录官方发布轨迹;

2.新的develop分支是一个集成分支,用来记录开发新功能的轨迹。

Master与Develop分支

除了master主线和develop主分支线,其他的分支都是临时的分支,有一定的生命周期的,其余的工作流程分支都是围绕这两个分支之间的区别进行的。

其他分支说明

-新功能分支(Feature Branches)

每一个新的功能都应该创建一个独立的分支,从develop分支中派生出来。当功能完成后,要合并(merged)回develop分支,合并后它的生命周期就结束。新功能分支不会与master分支有直接的交汇。如图:

[图片上传失败...(image-124599-1601368094316)]

Feature Branches

注意:对于所有意图和目的,新功能分支会合并到develop分支。但是,这个Gitflow工作流不会在此结束。

-发布分支(Release Branches)

一旦开发的功能已经满足发布条件(或预定发布日期接近),应该合并所有满足发布条件的新功能分支到develop分支中,然后,开出一个发布分支(Release),开始准备一个发布版本。在这个分支上,不能再添加新的功能,只有bug修复和该版本为导向的任务。一旦到了发布日期,Release就要合并回master发布,并且,打出版本标签。另外,还需要合并回develop分支。

[图片上传失败...(image-82c4c2-1601368094315)]

Release Branches

使用一个专门的分支来准备发布版本,使得一个团队能对当前版本进行抛光,而另一个团队继续为下一个版本的功能做准备。它还创造了良好定义的发展阶段(例如,很容易说,“本周我们正在准备4.0版”,而且真实地看到它在库中的结构)。

-维护分支(Maintenance Branches)

维护分支也就是线上bug修复分支,使用来快速修复生产环境的紧急问题。

[图片上传失败...(image-924d7a-1601368094315)]

Maintenance Branches

这个分支是唯一一个开放过程中直接从master分支派生来的分支。快速的修复问题后,它应该被合并回master和develop(或者当前发布分支),然后,master分支需要打一个版本标签。

一个专门的错误修复开发线,可以让团队在不等待下一个发布周期,导致中断工作流程情况下解决问题。可以将维护分支当做主要的问题修复分支,与master并行。

命名约定

-主分支名称:master

-主开发分支名称:develop

-标签(tag)名称:v.RELEASE,其中”“ 为版本号,“RELEASE”大写,如:v1.0.0.RELEASE**

-新功能开发分支名称:feature-or feature/,其中“” 为新功能简述,如:feature-item-activity-list*

-发布分支名称:release-or release/,其中为版本号,“release”小写,如:release-1.0.0*

-master的bug修复分支名称:hotfix-or hotfix/,其中为bug简述,如:hotfix/item-update-bug*

工作流程

下面具体演示如何使用工作流来管理版本发布周期。假设我们已经存在或创建了一个源码中央存储仓库。

工作流的基础

创建develop分支

[图片上传失败...(image-2d13a6-1601368094315)]

Create Develop Branch

-项目负责人在本地master基础上创建一个develop分支,然后,推送到服务器;

git branch develop

git push -u origin develop

-其他开发人员,需要克隆develop中央仓库的源码,创建一个develop的轨迹版本;如果,已经克隆过该项目,则,不需要执行以下第一条命令。

git clone git@github.org:search-cloud/demo.git

git checkout -b develop origin/develop

develop这个分支将包含项目的完整历史记录,而master将包含缩略版本。

** 假设开始以下所有的流程之前,都已经创建好develop分支。**

新功能开发流程

1.新建feature分支

[图片上传失败...(image-6d39ef-1601368094315)]

Create Feature Branch

基于develop分支创建新功能分支:

git checkout -b feature/demo develop

推送到远程仓库,共享:

git push

所有开发此新功能的人员,都在此分支上开发提交代码。

git status

git add

git commit -m "Add some-file."

2.完成新功能开发(合并feature分支到develop)

[图片上传失败...(image-d27df4-1601368094315)]

Merge Feature to Develop

当确定新功能开发完成,且联调测试通过,并且新功能负责人已经得到合并feature分支到develop分支的允许;这样才能合并feature分支到develop。

git pull origin develop

git checkout develop

git merge feature/demo

git push

git branch -d feature/demo

第一条命令是确保在合并新功能之前,develop分支是最新的。

注意:

-新功能分支,永远不要直接合并到master分支。

-合并可能会有冲突,应该谨慎处理冲突。

3.在测试环境发布develop分支代码(提交测试)

线上版本发布流程

1.从develop中创建准备发布的release分支

[图片上传失败...(image-ed3e1f-1601368094315)]

Create Release Branch

当主测试流程完成,源码已经趋近于稳定状态,应该准备一个发布版本,确立版本号:

git checkout -b release-0.1.0 develop

推送到远程仓库共享:

git push

这个分支是清理准备发布、 整体回归测试、 更新文档,和做其他任何系统即将发布的事情。

2.继续抛光改bug

3.release分支合并到master发布

[图片上传失败...(image-cf4dd1-1601368094314)]

Merge Release to Master and Develop

一旦已经满足发布条件(或已经到了预定发布日期),应该把release分支合并到master分支和develop分支中,然后,使用master发布新版本。合并release分支到develop分支是很重要的,要让release上修改的东西能在后续的开发分支中生效。

git checkout master

git merge release-0.1.0

git push

4.release分支合并到develop

git checkout develop

git merge release-0.1.0

git push

git branch -d release-0.1.0

5.打标签

Release分支在功能开发分支(develop)和公共发布版(master)中,充当一个缓冲的作用。每当有源码合并到master中的时候,应该在master上打一个标签,以便后续跟踪查阅。

git tag -a 0.1.0.RELEASE -m "Initial public release" master

git push --tags

线上Bug修复流程

当终端用户,反馈系统有bug时,为了处理bug,需要从master中创建出保养分支;等到bug修复完成,需要合并回master:

1.创建hotfix分支

git checkout -b issue-#001 master

2.修改bug Fix the bug

3.完成修复,合并到master发布

[图片上传失败...(image-8b6f79-1601368094313)]

Merge hotfix to Master

git checkout master

git merge issue-#001

git push

4.打标签

git tag -a 0.1.1.RELEASE -m "Initial public release" master

git push --tags

5.合并到develop

git checkout develop

git merge issue-#001

git push

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,902评论 5 468
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,037评论 2 377
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,978评论 0 332
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,867评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,763评论 5 360
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,104评论 1 277
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,565评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,236评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,379评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,313评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,363评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,034评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,637评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,719评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,952评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,371评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,948评论 2 341