欢迎来到爱学习爱分享,在这里,你会找到许多有趣的技术 : )

记一次常规的 gitflow 工作流

开发者头条 848℃

先简单说一下常见的git 分支管理策略

1.集中式工作流:类似于SVN管理方式,只有一个master分支,每个人将自己的代码提交到master上。
2.feature工作流:有一个主分支默认为master分支。每个人开发的时候基于master分支新建feature分支,然后提交到中央仓库,供大家code-review,通过之后merge进master分支。
3.gitflow工作流:长期存在两个分支,一个master分支,一个develop分支,develop分支为日常开发分支,所有功能开发都基于develop分支,测试也基于develop,测试通过之后合并到master分支。
4.forking 工作流:这个工作流和其他工作流有本质不同,其他工作流都是有一个服务端仓库,forking工作流允许每个开发者有一个自己的服务端仓库。每个开发者可以将修改push到自己的服务端仓库,然后发起一个pull request 项目拥有者将修改更新到本地,测试通过之后,合并到自己本地的master分支,然后推送到公共仓库。

以上四种工作方式除了第一种不能使用pull request其他都可以。
pull request 就是提交代码之后发起给团队其他人发起code review请求。

下面来具体说说gitflow 工作流,也是很多团队都在使用的工作流。
优点:就是打包上线,测试,开发,都很清晰。
gitflow工作流是由Vincent Driessen 提出的。其主要思想可以用如下图表示。

在Gitflow 工作流中主要体现两个分支:
一个master分支,所有上线的版本全部由该分支打包。
一个develop分支,日常开发基于该分支。
gitFlow 日常工作流程图如下

下面介绍一下使用gitflow 工作流的常规操作。
假设我们开发一个新的feature-1
操作如下:

1git checkout develop #切换到develop分支,保证最新。
2git checkout -b feature-1 #新建feature-1分支,并切换到该分支

做一堆修改,然后加入暂存区

1git commit -m "compelete feature-1" #一次commit操作
2git checkout develop #切回到develop分支
3git pull --rebase #检查更新,并以rebase方式更新到本地
4git checkout feature-1 #切回feature-1
5git rebase develop #将develop rebase到feature-1
6git push -u origin feature-1 #推送到服务端进行code review

code review,顺利通过。

1git checkout develop #切回develop
2git merge feature-1 #将feature-1 合并进develop
3git push origin develop #将develop 推送到服务端
4git push origin --delete feature-1 #删除分支
5git branch -d feature-1 #删除本地分支
6git checkout master #切回master分支
7git merge --no-ff develop #将 develop 合并进master分支

以上是一次完整的功能开发。

转载请注明:爱学习爱分享 » 记一次常规的 gitflow 工作流

喜欢 (0)or分享 (0)