GIT操作规范-Git Flow(下)之 实际操作

了解了Git操作规范的Git Flow模型介绍之后,我们可以开始在实际开发中使用了,下面我们按照场景来逐一说明

Git的基本操作不再详细说明,可以在Git官网 https://git-scm.com/doc

开始工作

仓库初始化和主分支的创建工作一般管理员在GitLab上已经操作完成,开发人员会得到通知获取仓库地址,只需要克隆develop分支到工作目录

克隆到本地

$ git clone [email protected]/demo.git (因涉及到公司项目 此处换成自己的项目地址)


切换到devlop分支

$ git checkout develop

这里为什么不是master分支?

因为开发人员没有权限操作master分支,并且devlop分支合并到master分支也是由专人负责,所以没有必要拉取master分支,当然这个并不是禁止。

开发新功能

现在我们接到产品经理的需求,需要做一个拼团功能,按照前面描述的模型,我们首先是创建一个feature分支。

$ git checkout -b feature/group develop

现在我们将在feature/group分支上开发拼团的功能

。。。

拼团功能已经开发完成,并且已经在拼团的分支上完成了测试,具备了合并到develop分支的条件,那么拼团的团队负责人执行个合并操作,并删除功能分支。

切换到develop分支

$ git checkout develop

将feature/group合并进来

$ git merge --no-ff feature/group

删除feature分支

$ git branch -d feature/group

推送develop分支

$ git push origin develop

发布版本

功能合并到develop之后还可以继续在develop分支上进行测试和修复Bug,一切完成之后产品经理决定发布第一个版本了,版本号 1.0。这里就会用到release分支了

从develop分支上拉一个新分支

$ git checkout -b release/1.0 develop

我们可以再次在release上测试和修复bug(仅限于修复bug,严禁在release分支开发新功能)。

修复完成了,切换到master分支,将release/1.0合并进来

$ git checkout master
$ git merge --no-ff release/1.0

打上标签

$ git tag -a 1.0

如果release/1.0分支有更新则需要再次将更改合并到develop分支

$ git checkout develop
$ git merge --no-ff release/1.0

删除release/1.0分支

$ git branch -d release/1.0

紧急情况

运营反映线上版本出现了严重的问题,需要马上修复,不能等到下个版本(记住这个条件)。hotfix分支的作用就在这里。

从master分支上拉一个新分支

$ git checkout -b hotfix/1.1 master

修复完成了,切换到master分支,将hotfix/1.1合并进来

$ git checkout master
$ git merge --no-ff hotfix/1.1

打上标签

$ git tag -a 1.1

同时要合并到develop分支

$ git checkout develop
$ git git merge --no-ff hotfix/1.1

删除hotfix/1.1分支

$ git branch -d hotfix/1.1

 

关于--no-ff

GIT操作规范-Git Flow(下)之 实际操作