GitLab实战演示,一篇文带你了解Git的分支管理策略
上一篇讲到Git的分支管理实操,在线合并和本地合并都进行了实操。毕竟:光说不练是假把式。而只练不整理,只能是傻把式了。分支管理到底如何进行管理呢?
先以GitLab上的一张经典的图打头,作为一个总体概览,也方便理解分支的管理和走向:
** 场景预设**
现假设公司有名为Hogwarts_Online2的开发项目,其中包含了上线分支master
,开发分支develop
,测试分支release
,和个人开发的特性分支`
** 特性分支与develop分支**
1.1)与远程仓库建立连接,在本地创建自己的分支,并拉取develop分支的文件:
1.2)在当前分支中创建新的文件gitflowDemo.txt
,输入内容“study git”;然后add
,`commit```
#修改分支vi gitflowDemo.txt#提交修改git add gitflowDemo.txtgit commit -m "add demo"
1.3) 通过git pull
命令检查远程develop分支是否和当前分支有冲突:
$ git pull origin developFrom ssh://47.95.238.18:10022/root/hogwarts_online2 * branch develop -> FETCH_HEADAlready up to date.
注: __
push之前先拉去远程代码,以防在开发过程中,远程被别人更新过新版本代码。如有代码冲突,两人协商冲突解决办法。多人开发的时候,冲突是不可避免的。
1.4) git push
将修改推至远程特性分支origin gitflowDemo
:
1.5) 在GitLab上进行merge request
,并在develop分支上进行merge
:
如果想要撤回这次merge可用
git merge --abort````
create merge request:
选择develop分支: __
没有冲突,可直接merge: __
最终我们可以看到成功 merge
进develop分支中:
我们还可以在graph
中查看分支的走向:
这样,特性分支和develop分支的代码拉取与合并就完成了
另外,工作中develop分支可能是权限比较开放的,允许push的,这时候我们就可以在本地直接修改merge然后push到远程develop中
修改gitflowDemo.txt文件为
study gitupdate
add
,commit
,`push```
git add gitflowDemo.txtgit commit -m "update gitflowDemo.txt"git push -u origin gitflowDemo
``切换到本地develop
分支,pull
最新代码,merge
本地gitflowDemo
分支代码,push
进远程develop
分支
git checkout developgit pull origin developgit merge gitflowDemogit push -u origin develop
这个是在GitLab上检查更新情况:
** release分支**
develop
分支变动频繁,master
分支属于上限版本,因此需要一个内测的分支版本,这个就是release
分支了
具体的提交操作根据权限范围,和1中develop的操作一致。
** hotfixes**
有的时候出现的非常紧急的bug,需要立即修改上线,来不及在各个分支上进行merge
测试了;这个就是就需要用hotfixes
模式,建立一个bugfix
分支,直接绕开其他分支,修改合并到master
中。
注:这种未经测试就上线的情况很危险,本人就遇见过;之前驻场在华为里工作的时候,组内一位开发同事修改了一两行的代码,觉得不会有问题就直接跳过了我们测试,通过别人直接上线发布了,当时我所在的组是GNSS组;结果直接导致一千多万台手机的定位功能有失效的风险,受到了很多投诉,影响很大;最终相关开发人员被紧急停止休假,我们测试组也十一加了七天班,为了这个小小的改动付出了不小的后果~
3.1) 建立bugfix分支,并修改文件push到远程分支:
git checkout mastergit checkout -b bug_02fix
vi bugfix02.txtfix bug02
git commit -a -m "bug_01 fix"git push -u origin bug_01fix
git add bugfix02.txtgit commit -m "fix bug02"git push origin bug_02fix
3.2) 这个时候检查GitLab,会发现多了一条从master
分支拉出来的修改bug02的分支:
3.3)最后由最终的master
权限拥有者来进行合并。
3.4)修改了bug直接上线master
后,很有可能让master
分支的修改已经领先其他分支了;这个时候就需要将其他分支更新,对master
分支进行合并;同时将bugfix分支删除,尽量保证分支的整洁度。
** 补充**
4、补充
git log
git log --graph --all --decorate=shortgit grep "pattern" $(git rev-list --all)git log f13297
rebase
变基,合并分支后可以将分支走向的基准线变更,在分支很多的时候,可以简化分支的展示,合并分支走向使流程看起来简洁一点
git checkout featuregit rebase master
与merge后的分支走向对比:
git checkout featuregit merge master#或者写在一行git merge feature master
此外,rebase还可以对提交的历史进行修改(不常用也不建议使用)
git rebase -i HEAD~2
注意 : __ rebase的使用规则
1、不要在公用的分支上执行rebase
`2、主要的分支进行保护```
git diff
git diffgit diff HEAD~3git diff master develop
常见diff工具:
-
diff ——仅展示某一行的增加(+)或减少(-)
-
vimdiff ——比diff看起来要更直接
-
IDE ——强大的工具,展示清晰,使用方便
vimdiff bugfix01.txt bugfix02.txt
参考链接:
git的基本使用流程:
https://www.atlassian.com/git/tutorials/setting-up-a-repository
特性分支工作流:
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-
workflow
gitlab工作流:
https://docs.gitlab.com/ee/workflow/gitlab_flow.html
多种工作流对比:
https://www.atlassian.com/git/tutorials/comparing-workflows
gitlab私服搭建:
https://docs.gitlab.com/omnibus/docker/
作 者
AUTHOR
月关,霍格沃兹测试学院优秀学员。一个在质量保障领域攀登探索的tester,致力于用技术改变身边人对测试的认识。对Web,接口和APP 自动化均有所涉及。
往期推荐
福利 |
学会Jenkins自己部署测试环境,让你工资high到飞
基于Junit4,利用xUnit框架让你的测试用例可维护性大幅提升
- 今日互动 -
欢迎文章下方留言并分享给其他测试小伙伴哦~
**
来霍格沃兹测试开发学社,学习更多软件测试与测试开发的进阶技术,知识点涵盖web自动化测试 app自动化测试、接口自动化测试、测试框架、性能测试、安全测试、持续集成/持续交付/DevOps,测试左移、测试右移、精准测试、测试平台开发、测试管理等内容,课程技术涵盖bash、pytest、junit、selenium、appium、postman、requests、httprunner、jmeter、jenkins、docker、k8s、elk、sonarqube、jacoco、jvm-sandbox等相关技术,全面提升测试开发工程师的技术实力