刚进公司,不懂GIt工作流的我瑟瑟发抖

发布于 1970年 01月 01日 08:00

前言

不懂git工作流,被辞退了!

之前在看到这句话的时候,我刚实习入职不久,瑟瑟发抖。好巧不巧,今天又看到了类似的文章讲git重要性的。

image-20220118135322392

眼下,学校导师安排给我的课题组了一个新的工程项目,使用gitee维护,因此我打算写一篇文章总结一下git的工作流(git工作流就是指单人/多人团队如何使用git命令配合维护一个项目的一些约定的流程,在确保有效迭代的同时,保持高效的协作方式),相信可以帮助那些使用git停留在单人维护远程master分支的同学更进一步。

image-20220118113156944

下面会讲解四种git工作流中的前两种,无论是在校课题组还是公司内部,都可以以此为基础找到合适的git团队工作模式。

Centralized Workflow 集中式工作流

介绍

image-20220118120940091

三个开发人员共同维护一份远程仓库的代码,工作方式如下:

  1. 每次工作前从remote拉取master分支到本地的master分支,然后处理冲突(使用IDE自带的GUI图形用户界面处理冲突会比较方便,如图中的goland内置的git工具)

    image-20220118121723074

  2. 接着开始编码,编码完成后add修改的文件到缓冲区

  3. commit缓冲区文件到自己local仓库,并且push本地仓库文件到remote仓库

评价

集中式工作流:这种工作方式简单粗暴,所有人只使用master分支维护项目,master永远是项目最新版本,编码比较快,立竿见影。但是所有开发者提交日志集中在一起呈单线延伸,难以定位问题,分工不明确,且容易发生冲突,处理冲突成本上升,但是单人开发很便利。

Feature Branch Workflow 功能分支工作流

介绍

image-20220118164211461

功能分支工作流以集中式工作流为基础,在维护master分支的基础上,将项目的开发工作拆分为添加一个个的feature的形式,工作方式如下:

  1. 一旦需要开发新的功能,就在remotemaster分支的基础上创建一个feature xxx分支

  2. 本地创建对应的feature xxx分支

  3. 每次开发前将remote库feature xxx分支拉取到本地,处理冲突

  4. 然后在本地feature xxx分支上开发,然后push到remote的feature xxx分支

  5. 在项目主页上发起pull request(如果是gitlab则是merge request,作用相同),本意是提出将feature xxx分支合并入master分支的请求

    image-20220118163039576

  6. 然后你的代码会被review,没通过就本地改,改完之后继续pushremote(两头都在feature xxx分支),然后负责人继续review你这个PR或者MR,通过之后会将feature xxx分支区别于master的改动合并入master,删除remote的feature xxx分支,代表这个功能开发完毕

评价

功能分支工作流:这种工作方式带来了code review的功能,使得推送的代码更符合规范,减少bug产生。并且因为主要还是在master分支基础上根据功能需求创建feature分支,使得开发工作十分灵活,且各个功能之间隔离,但是对于大型项目而言需要为不同分支分配更加具体的角色,只有feature分支是不够的

Gitflow Workflow

介绍

image-20220118190551888

Gitflow工作流是我目前尚在熟悉的一种工作流,也是目前非常成熟的git工作流方案。区别于功能分支工作流,Gitflow工作流划分分支更有约束性。主要包括:

  1. 主分支master:用于跟踪项目正式发布的版本(tag标签号)
  2. 开发分支dev:用于跟踪代码研发的提交历史
  3. 功能研发分支feature:每次有新的功能需要研发,以dev分支为基础,建立feature分支,开发完成后按上面feature branch工作流的方式提交PR/MR到remote的dev分支,完成之后删除对应feature分支
  4. 热修复分支hotfix:如上图所示,master分支出现bug(线上报bug了),需要马上从master拉取一个hotfix分支处理修复bug,并且将代码合并到master和dev(这两个分支需要保持bug修复的一致性),修复后给master当前提交打一个tag(v0.2)
  5. 发布分支release:在dev基础上建立release分支,处理一些问题、修复一些bug之后,将代码合并入master与dev,并给master打上tag(v1.0)表示发布完成

评价

约束性更强,发布迭代流程更规范,严谨,开发人员分工更明确,十分推荐学习使用。

Forking Workflow

介绍

image-20220118201450505

这种工作流是开源项目维护的工作流,暂作了解即可,通过将他人的项目fork到自己的remote仓库,就可以将其作为自己拥有的一份副本进行开发,比如想增加一个功能或者修复一个bug。这里A与C都fork了B的仓库,在各自开发完成新功能之后可以提交PR给B仓库,B仓库的开发者负责review代码,并接受PR。

评价

具体还未尝试过提交PR给开源项目,但是相信在掌握了上述三个git工作流之后,以后要使用到forking工作流的问题也应该引刃而解。

结束

学习了四种git工作流之后,并不是要完全照搬某一个模式的所有使用流程,而是应该结合实际的项目规模和人员规模进行合理安排。比如对于校内课题组较小的项目我认为feature branch工作流应该足以胜任,或者使用只有masterdevfeature的简化版Gitflow工作流

我是白泽,一个有点逗比的程序员/学生党,咱们下期见。

欢迎大家关注公众号【程序员白泽】。

传送门

刚建了个微信小群,欢迎一起交流学习,备战秋招。

传送门