大话 Git 工作流

深圳的秋天,比全国大多数地方都来得更晚。在经过忽冷忽热的挣扎中,天气渐渐转凉。 这天是周末,晚上天气凉爽,小刘,小李,小高,小陈四个人,约好一起来撸串。他们是大学同学,学的是计算机,毕业后都到了深圳,目前都以写程序为生,加入了程序员大军。

程序员的聚餐节目是固定的,几口大腰子下去,再加上几杯啤酒下肚,几个人不约而同的开始各种吐槽,从骂老板,骂上司,骂产品,骂设计,骂到最后,大家都懂。所谓的程序员的聊天以骂老板开始,以撕编程语言结束。

但是今天他们又开了一个新的话题,那就是代码托管的工作流。

小刘率先发言,git 这货 跟 svn 没啥差别,我一贯还是按照以往的,写完了就提交,我们三五个人的小团队也都这样,除了可以在本地不连服务器上也能提交代码这点之外,跟 svn 没啥差别,我们就只有一个主分支跟 svn 的主干是一样的,大家都在这上面工作,团队协作沟通非常高效。

小刘所讲的工作流 – Centralized Workflow

图片

这套流程讲究的就是快速,简单,这对于大多数个人开发者和小型团队来说是最好的选择,往往是维护一个 App,个人博客,或者一个小型网站之类的。总结下来适用场景和基本特点是: 

  1. 团队人数少
  2. 开发不是很频繁
  3. 团队沟通方便
  4. 不需同时维护多个版本

继续说回我们的故事。 小陈听不下去了,说道:我们团队都推行使用一个 git 的插件,叫做 git-flow, 所有成员,都按照这个软件规定的标准流程进行协作,每次改动,我们都根据不同的情形,使用 git-flow 工具来新建相应的流程。大家都按照这个流程来,虽然繁琐,但是我们三十几个开发团队共同维护几个项目,从来都是运行平稳,从未出事,就你们那几个人三天两头代码库被新手搞乱,居然还好意思叫团队协作沟通高效?我看是搞笑吧,哈哈。

小刘气的脸通红,又没啥话好说,只好忍了。

小陈所讲的工作流 – Git-flow Workflow

图片

这套工作流讲究的是平稳,有序,Git-flow 工作流在 Git 分支标签等概念的基础上,添加了一些 Feature,Release,Hotfix 等概念,用以精确描述代码版本控制的一些流程,所有协作者在放弃一些个人效率的基础上,统一开发流程,最终带来的是整体的规模化的团队的整体效率提升。其缺点是上手较难一点,需要一些基础知识培训,适用场景如下:

  1. 认为额外学习 Git-Flow 不是什么问题的
  2. 有专门的代码仓库管理员的
  3. 开发团队相对固定,而且有一定规模
  4. 常常有并行开发需求
  5. 团队对于 Release,Bug,Feature 这些概念有统一定义标准的

继续说回我们的故事。 这时小李淡定的拿出一串羊肉,吃了一口,说道:我不知道你们说的是什么玩意,但是我作为一个自由职业者,维护着一个开源软件,平时也给一些开源软件贡献些代码,从来都是 Github 上 fork 完了,再提交 Pull Request 的,Pull Request 会被开源软件的维护者评审,如果评审通过,就会合并到源项目。我作为一个开源软件的维护者,既评审着别人给我的贡献,也贡献给别人评审,这是一个非常理想的生态循环,我不知道你们扯那些破玩意有啥用。

小李所讲工作流 – Fork Workflow

图片

这套流程是专门为开源软件量身打造的一套流程,最早的发明者是 Github,Github 是世界知名开源软件仓库。这个流程的最大特点就是,开发参与者可以不直接参与到项目中来,想贡献代码,只要 fork 目标项目后,就可以得到一个一模一样的自有项目,做完修改后,提交 Pull Request 给原项目,如原项目的维护者采纳了,即算贡献完成。图中看一看到,每个开发者(团队)都拥有自己维护的一个项目,跟别人项目之间的联系通过 Pull Request 形式解决。总结下来适用场景是:

  1. 常用于开源软件
  2. 开发者有需要衍生出自己的衍生版的
  3. 开发者不固定,可能是任意一个网友

继续说回我们的故事。 小高是个胖子,每次撸串最能吃,基本上聊天的时候都是偶尔插一句话。但是这时候,听完这一顿撕,也忍不了了,用纸巾擦掉嘴上的辣椒说道:我们公司,跟你们选择的都不同,我们公司使用基于 git-flow 简化的一个模型来协同工作,不需要安装什么 git 插件。版本库有一个默认分支 master ,需要 release 的时候,就将默认分支打一个标签,用作 release 。使用 Coding 提供的保护分支功能, master 指定若干管理员,其他人有任何修改都在默认分支 master 的基础上新开分支,提交代码,然后到 Coding 上向 master 提交合并请求,并可以指定若干团队成员作为评审者,评审通过后就可以合并到 master 上了。也从来都运转平稳,从未出事。

小高所讲工作流 – Feature Branch Workflow

图片

这套流程属于 Git-Flow 的简化版,不再需要安装额外 Git 插件,基于代码托管平台提供的一些基础功能来实现,主要流程分 Feature 流程和 Bug 流程。这个流程是适用于大多数团队人数在 5 人以上,有很多并行开发需求,切更新频繁,开发任务重的协作团队。其适用场景是:

  1. 开发团队相对固定,而且有一定规模
  2. 常常有多个功能,多个问题并行开发
  3. 对代码审查有较高要求
  4. 更注重团队效率

小刘,这时才从小陈的话中缓过神来,对小陈说道,我们虽然是出过新手搞乱了代码库的问题,但是 git 都是有历史的,并非不可恢复,关键是我们流程简便,从来有任何问题都是快速响应,不像有些公司,修个 bug ,居然要等一周才能上线。

小李又说道,有啥好吵,都是没啥卵用的玩意,你就按照 fork / pull request 来搞就行了。

你一句,我一句,七嘴八舌的,吵得不可开交。 。。。。。。

这四位的争论越来越激烈,没办法,程序员的争论都是撕破脸皮,面红耳赤,直至烧烤店快要打烊了。最后惊动了烧烤店的老板娘。老板娘听罢争论,笑眯眯的走过来说:年轻人莫要激动,我虽然不知道讲什么,但这世间万物,都有适用范围,没有什么是绝对好的,也没有什么是绝对坏的。就好比你们吃烧烤的辣椒,放在这烤肉上,味道就非常不错,但是你见过哪家冷饮店放辣椒的么?

几人听完,瞬间觉得卫生阿姨就好比金庸小说扫地僧那般神奇,细思恐极,赶紧结了账,匆匆离开了。

============ 这是分割线 ============

是啊,没什么是绝对好的,也没什么是绝对坏的,每样东西都有适用范围。

以上,适用场景并不定死,是灵活多变的,甚至于我们可以超出以上四种模型,取其精华,弃其糟粕,自己创造出新的模型来。总之,希望这篇文章能帮助你找到属于符合自己的模型的 git 工作流。

相关文章