GIT操作规范-Git Flow（下）之 实际操作

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

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

开始工作

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

克隆到本地

$ git clone git@gitlab.corp.xxx.com/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