GitFlow with SourceTree

0.992字数 3266阅读 6575

网上关于Git-Flow的教程一大堆,哎呀,命令行太多记不住啊。还好有SourceTree,但是好像功能还挺多,不知道什么时候选择什么功能,新版的SourceTree和网上的教程的截图貌似对应不上。正好我最近也在学习Git-Flow,好记性不如烂笔头啊,光说不练假把式,我们开始吧。参考教程

一. 首先配置环境

前往SourceTree下载这个免费强大的Git GUI工具。安装过程略,你需要注册个SourceTree的账号。
本文基于SourceTree 2.5.1 mac版,Windows界面差不多。

SourceTree.png

如果你的电脑还未安装Git的话,首先得安装Git,同样安装过程略。mac用户建议使用HomeBrew来安装Git。Windows用户建议使用安装包来安装Git,这样会自动将git加入到环境变量中。

二. GitFlow

  1. 创建本地和远程仓库
创建仓库.png
image.png

创建好了会自动打开操作窗口


image.png
  1. 做第一次提交(确保至少提交一次到本地仓库,这样才会创建master分支)
    如果不提交一次的话,GitFlow就无法初始化,因为其不知道以哪为基线(因为master分支尚未创建)。
    这里我就在本地的Test文件夹创建个文件,然后在SourceTree的文件状态里对这个文件加入索引,再点击提交。


    image.png

    image.png

    提交后就会发现分支有个master分支了:


    image.png

    如果需要重命名则点击菜单的“移动”选项
    image.png
  2. 初始化GitFlow

注意:初始化操作需要在团队每位成员电脑上均进行一次,各配置需保持一致.应由仓库管理员创建仓库

按快捷键Command+Option+F 或者菜单 仓库——GitFlow——初始化仓库
如果在master分支上没有做任何提交的话,GitFlow是不会初始化成功的,会报错如下:

空仓库初始化git-flow.png

有过提交记录的master分支可以正常初始化git-flow
image.png

image.png

确定后会出来个develop分支
image.png

  1. 推送到远程服务器
    注意只需要推送master和develop分支,如果你现在已经创建了feature或release或hotfix分支都不要推送,远端只需要master和develop.


    image.png
  2. 新增Feature分支(功能)
    老样子 Command+Option+F 打开GitFlow菜单,选择 “建立新功能”


    image.png

    输入新功能名称:


    image.png

    现在会创建feature,并自动切换到当前feature分支:
    image.png
  3. 在新创建的feature分支中进行开发:
    比如我这里添加了个新文件:


    image.png

    右击文件添加索引后提交:


    image.png

    提交后的状态如下:
    image.png

此处省略一系列的开发提交过程。

  1. 完成feature功能开发


    image.png

    点击“完成当前版本”按钮,弹窗如下:


    image.png

    这里主要讲下“在开发分支上进行变基”(rebase)这个勾选框,如果勾上则表示保留在这个feature功能上的提交历史到develop分支上,不勾选则合并这个功能模块的提交历史成一个(Merge某某功能到develop)。默认是不勾选的。一般使用默认选项即可。
    image.png
  2. 发布release分支

release分支总是由develop分支发起


GitFlow-release分支.png

填写版本号.png

image.png

研发这个时候应该切回release分支,将这个分支上的代码编译然后部署到测试环境中供QA测试,这个时候团队一方面应该做代码ReView工作,一方面要响应QA那边反馈过来的bug,然后在这个release分支上做修复/修改工作。
例如我这里简单的提交一下:


image.png

当QA觉得OK了,代码ReView也通过了,那么就可以“完成发布版本”
image.png

打标签,撰写发布日志、更新内容.png

“以此消息打标签”这里应该写详细的更新内容,比如新增了XXX,修复了XXX,优化了XXX等,不应该像我截图那样直接写个版本号在上面。
image.png

此时应该推送到远端仓库完成真正的发布:


image.png

远端仓库你应该能看到新发布的:
推送.png
  1. hotfix 分支(紧急修复线上版本bug)

git-flow假定当前产品线只需要维护一个版本,所以Git-Flow的hotfix总是基于最新的master分支里的版本来开辟的。如果需要同时维护多个版本,那么就不应该用master分支了,可以多建几个分支比如1.x分支,2.x分支,3.x分支,这样就可以同时维护3个版本线的产品,但是所带来的维护量就变的很大了。所以建议大家只维护一个版本来做CI(持续集成)
Git-Flow的hotfix分支和release分支有点像,区别在于release分支是由develop分支拉取出来的新分支,而hotfix分支是由master分支拉取出来的新分支,两者最终都会合并入master和develop分支。只不过hotfix用于生产环境中的紧急修复,需要快速响应和修复,减少Code ReView和QA环节的时间(不是说不做,只是说尽量快点完成这两个环节,尽量快点修复,否则大批用户都会受这个bug影响,毕竟是生产环境。)

假如QA同学发现线上版本有个bug需要修复,他应该在Git的工单系统里把bug详细叙述了一下


image.png

注意issue后面的#1这是issue的代号。后面可以通过commit信息来关闭这个issue
回到SourceTree,切回到master分支上:


建立新的修复补丁.png

image.png

image.png

在这个hotfix上做bug修复,


image.png

如果你确定修复了某个issue,可以在提交信息中写fix #1 或close #1等信息来直接关闭某个issue。
修复完毕后,继续Command+Option+F 打开GitFlow菜单:
image.png

撰写新版本发布内容、更新日志.png

提交推送.png

推送完毕后,我们来看看网页:
image.png

大家有没有注意到issue已经被关闭了,在release那里也能看到新发布的版本。
image.png

三. 总结

  1. GitFlow有5大分支:master(主干)、develop(开发)、feature(功能)、release(预发布)、hotfix(热修复)。这里说下release分支,其实正名应该叫发布分支,我为什么叫他预发布分支呢,因为这个release分支并不是真正的发布,他是由develop分支经过多次feature功能迭代后分出来的一个分支,告诉大家这些功能准备的差不多了,可以准备发布了,但是实际上并没有发布。release分支创建好后,应由QA做测试,研发一起联调,然后先发布到测试环境中进行测试,QA如果觉得有问题,可以先提交工单给研发,研发在这个release分支上做小幅度bug修复,如果QA觉得可以使用的时候再由研发完成发布功能,此时release分支上所做的更改会被合并入master和develop分支中,release分支会在合并后被删除。
  • master

    定义:生产环境分支
    作用:记录每一个正式发布版本,TAG所在分支
    合并关系:允许release\hotfix分支的合并
    建立时机:仓库初始化
    初始代码来源:仓库创建

    • develop

    定义:开发分支
    作用:保持最新的开发代码
    合并关系:允许feature\release\hotfix分支的合并
    建立时机:master创建完成
    初始代码来源:master

    • release

    定义:发布分支
    作用:表示一个正式发布版本(我更倾向于叫他预发布)
    合并关系:不允许任何分支合并
    建立时机:线上代码满足发布要求
    初始代码来源:任意线上commit,推荐使用develop最新commit
    完成操作:合并至master/develop、打相应的TAG

    • feature

    定义:新功能分支
    作用:独立的功能需求
    合并关系:不允许任何分支合并
    建立时机:需要开发新的功能
    初始代码来源:任意线上commit,推荐使用develop最新commit
    完成操作:合并至develop分支

    • hotfix

    定义:修复BUG分支
    作用:用于修复已发布版本BUG
    合并关系:不允许任何分支合并
    建立时机:发布版本出现BUG
    初始代码来源:master(source tree 没有提供历史发布版本的hotfix创建,如需要可手动操作)
    完成操作:合并修改内容至master/develop分支

  1. 远程仓库仅仅应该存在两个分支,一个是master分支,存放线上(生产环境)版本,这个分支的代码总是可靠可用的;另一个是develop分支,这个分支用于日常开发。
  2. 本来master分支上的内容不应直接提交(除了第一次初始化GitFlow前需要至少提交一次在master分支上,确保master里面有内容),master分支总是应该由develop分支发布到release分支,经过QA测试确认可以上线后(期间可以在release分支上进行小幅bug修复提交更改),再完成发布新版本功能然后合并入master分支(发布成功后release分支会被删除,在release分支上所做的更改会自动合并到master和develop分支上)。但是如果在GitFlow已经初始化后(develop分支已经有了)不小心在master上直接提交了新的commit,这会导致develop分支上缺少主干master分支上的内容,这个时候就需要先将master分支推送到远端,然后本地切回到master分支,然后再使用pull功能从master分支上拉取内容到develop分支(SourceTree会警告正要从未跟踪的分支上拉取内容,点继续),这样就把master上所做的更改来回到develop分支上了。 虽然有这个曲线救国的办法,但是平时在使用的过程中还是要注意规范,尽量避免这种情况。
  3. feature 分支 下可以有多个feature同时在开发,并不影响。feature最终是提交到develop分支上的,release是从develop分支上拉取的,release分支是提交到master分支上的(develop分支不能直接提交到master上),他们几个并不冲突。允许在仍然有feature在开发的情况下从develop分支拉取到release分支。


    image.png
  4. 如果建立了某个开发功能(feature)或者发布版本(release)分支后,如果不想开发或者发布了,可以先切回到其他分支(比如master或develop分支),然后在要删除的分支上右击,选择“删除分支”


    image.png
  5. 讲下如果线上发布版本的内容或者版本号写错了,在网页上直接删除即可。


    image.png

    例如我这里的“fixLoginBug”应该填写的是“1.0.1”版本号,但是当时提交的时候却写错成修复内容了。
    删除即可。删除完了记得会SourceTree里Pull 拉取远程仓库的更新内容到本地。

  6. 本文为了演示方便,提交信息以及发布日志(更新内容)极不规范,实际开发中应该规范提交信息,在大方面做到尽可能的详细。请参考这个commit模板
    例如,
fix: Add TimeUnit null check test case in Timed #5231
* Add TimeUnit null check test case in Timed
* Correct ugly formatting in BasicIntQueueDisposable
* Reformatting line
* Add blockingIterable’s negative buffer size fail test,close #5232
* Modify BlockingMultiObserver field’s modfier to private,fix #5231
* Revert style, modifier
* Remove duplicated test case.
* Remove no need annotation and variable

标题总结了此次提交的主要改动的主题(如果此次提交涉及或者修复了某个issue,建议在标题里用#来引用这个issue,如果是确认修复了这个issue建议在提交信息使用fix #222 或者close #222 来自动关闭对应的issue),然后在下面详情里每一行阐述具体改动了什么(或者说为什么要这么改)(为了修复XX,增加了XXX,重构了XXX,修改了XXX,移除了XXXX)每一行最好以常用动词开头。

  1. 多人协作的时候,应由仓库(项目)管理员来创建master分支并在本地初始化好GitFlow后一并将master和develop分支推送到远程仓库(master分支默认有写保护,只有创建者才能写入推送,其他协作者只能pull拉取)。其他协作者将项目克隆下来,同样要记得初始化GitFlow,注意配置要保持一致。其他协作者在本地完成feature开发,然后推送到develop分支,由项目管理员来负责发布release分支和发布新版本

关注我的公众号.jpg

推荐阅读更多精彩内容