Git Flow 和那些 Git Workflows

好的工具,可以改变我们的思维方式

什么是 Git Flow

2010 年初,荷兰的程序员 Vincent Driessen 在他自己的博客 http://nvie.com/ 发表了一篇文章 《A successful Git branching model》 ,在开源世界引起了一阵不小的关于 Git 工作流程的讨论,这篇文章里提出的 Git Flow 也成为了很多软件开发的事实标准。

Git Flow 就是 Vincent Driessen 在使用 Git 的过程中总结出来的一套工作流程(一种 Git Workflow)。这套流程非常适合互联网项目开发,这个流程约定了一些 Git 使用方法,让开发者可以井井有条地组织 Git 的 commit 和 branch 等操作,方便地完成项目的开发、测试、发布等环节。

几年来,这个流程已经成为业界的事实标准,关于它的介绍到处可见,在此只对其中几个要点做摘要:

  • master 分支只做发布
  • 每一个特性开一个 feature 分支(或者叫做 topic 分支)
  • feature 分支来自 developer 分支,也将被合并到 developer 分支
  • release 分支来之 developer 分支,将被合并到 master 分支 (或合并回developer分支)
  • 修改线上bug时,从 master 分支开一个 hotfix 分支,将被合并回 master 分支

事实上,Git Flow 并不能算是个非常简单的工作流程,其每一步的操作,都需要若干个 Git 命令来完成。 作为一个自称 “tech enthusiast who breathes code and loves creating beautiful software” 的极客,Vincent Driessen 当然不能容忍这种机械且易错的流程,很自然地,他开发了一个 Git Flow 工具 gitflow

gitflow 提供一系列抽象层次更高的命令,来更快捷的完成 Git Flow , 例如:

  • git flow feature start [] // 开始一个特性的开发
  • git flow feature finish // 完成一个特性的开发
  • git flow release start // 开始一次 release
  • git flow release finish // 完成一次 release
  • git flow hotfix start // 开始一个线上bug修复
  • git flow hotfix finish // 完成一个线上bug修复

这些高层的命令调用了 git 的分支操作来实现其目的,让整个流程更加便捷,也减少了错误的产生。

有人说 Git Flow 的一个缺点就是需要用命令操作,多数图形界面还是要手工操作 git 命令。也许曾经是这样,但是大名鼎鼎的 Git 图形界面工具 SourceTree 早已经官方支持 Git Flow 了,这也可以证明 Git Flow 是一个已经被广大开发者所熟悉和接受的工作流。

说了半天,Git Flow 到底有什么好处,这个嘛,谁用谁知道。

其他的 Git Workflows

既然 Git Flow 只是一种 Git Workflow,这么说,还有其他的 Git Workflows 咯?

GitHub Flow

这个是 GitHub 自己使用的流程,也就是他们开发 github.com 使用的流程,而不是这些开源项目使用 GitHub 的流程,哈哈。
也许是他们认为 GitFlow 太复杂,更可能的是因为 GitHub 早于 Git Flow 诞生,所以 GitHub Flow 是一个非常简单的流程,大致的要点如下:

  • master 上任何一个 commit 都应该是可部署的
  • 要做改动,从 master 开一个新分支
  • 改动完成,开一个 pull request
  • 某个负责人确认了改动之后,就可以将其合并到 master 了
  • 合并到 master 之后,应该被立即部署

这个流程简单到吓人,GitHub 大概有 15 到 20 人在同一个项目(github.com)上使用这个流程,每天,他们可以完成数十次部署。

这个流程简单的让人流口水。然而,只有内功达到一定程度的高手,才能使用最简单的兵器御敌制胜。“飞花落叶皆可杀人”,可不是人人都能做到的,口水先咽到肚子里吧,盲目跟随,小心死得很难看呀.

Centralized Workflow

集中式工作流程 (https://www.atlassian.com/git/workflows#!workflow-centralized) 实际上,这就是 svn 使用的工作流程,大家在同一个集中管理的仓库上开发,各自在更新的时候负责解决冲突。是的,我们在 svn 时代一直使用这种工作流程,现在看来,是不是很难忍受了?

Feature Branch Workflow

https://www.atlassian.com/git/workflows#!workflow-feature-branch
这个工作流程已经很接近 GitFlow 了,或者说,它是个简化的 GitFlow,只是强调了 feature branch,没有 developer 和 release, hotfix 等分支概念,它和前面提到的 GitHub Flow 也很类似。

Forking Workflow

https://www.atlassian.com/git/workflows#!workflow-forking
这是一个基于多个代码仓库的工作流,每个开发者在自己的仓库上进行开发和提交,然后在不同仓库直接进行合并。在自己的仓库中,又可以按照独立的分支管理方式(工作流程)来进行开发,最后,向上游管理者发起 pull request 来进行合并。GitHub 上的大多数开源项目都用了这个工作流程。

更多 Git Workflows …

小结

为什么在 svn 时代,没有产生这么丰富的工作流程? svn 也有 branch 的概念,为什么大家没有像用 Git 这样来用 svn?

svn 里的分支,并不是 svn 本身的概念,而是用户使用svn时候的“约定”,也就是说,“分支”对于svn来说,就是一种工作流程,“分支”所在的抽象层次,相比 svn 提供的抽象层次,已经高出了一级。

对于一个工具来说,在用户熟练使用后,一般可以衍生出一些使用“文化”,也就是一些约定的”惯用法“或“工作流程”,然而这些“文化”一般只比工具提供的抽象层次高一个层次,也就是说,这些“文化”是可以通过工具提供的基础功能进行重复、组合等方式来实现的。

svn 里的“分支”,就是利用svn基本的目录功能来实现的,并不是 svn 直接提供的,因此,它是在比svn 抽象层次更高一级的层次上的。而本文提到的 git 的丰富的工作流程,多数是由“分支”这个概念衍生出来的,对于 svn 来说,这种工作流程已经是高于其两个抽象层次的逻辑,对于人类这种生物来说,可能确实比较困难。

而 git 中,有了 branch 等更多的基本概念,使用 git 完成各种工作流程,还是仅仅提高了一个抽象层次而已,对人类来说没有障碍,所以各种流程百家争鸣。git 不过是比 svn 提高了一个抽象层次,却给开发者带来了更广阔的天空。

乘法确实就是加法的叠加,但从这种运算中涌现出了新的力量,如果我们只把乘法看成是加法的重复,就永远不可能掌握这种力量,只满足于加法,就永远得不到 E=mc^2
— Kevin Kelly

参考资料

  1. http://nvie.com/posts/a-successful-git-branching-model/
  2. http://www.syntevo.com/smartgit/documentation/6/show?page=git-flow
  3. http://www.jiangyouxin.net/
  4. 基于git的源代码管理模型——git flow
  5. git flow的简单使用
  6. https://guides.github.com/introduction/flow/index.html
  7. http://scottchacon.com/2011/08/31/github-flow.html
  8. http://blog.endpoint.com/2014/05/git-workflows-that-work.html

Git 比 SVN 好在哪里?


/*
  虽然很早就开始用 Git 了,但由于 SVN 的烙印太深,还是花了很久才逐渐习惯了Git的思维模式。Git 对开源软件开发来说,可谓不二选择,但对于公司内的一般软件项目,并没有太大的优势,然而相比 SVN 还是要好一些….
*/

一点历史

2002 年,Linux 内核开发团队决定使用一个叫做 BitKeeper 的版本控制工具来维护内核版本的代码,这是一个商业软件,由 BitMover 公司开发,BitMover 的 CEO Larry McVoy 也是一个 Linux 内核开发者。

2005 年,BitMover 和 Linux 内核社区关系破裂,内核开发者不能继续使用BitKeeper。于是,当家老大 Linus Torvalds 设计和开发了 Git 来代替 BitKeeper。

一开始,社区还有不少反对的声音,因为 Git 比较晦涩难懂,使用不方便,但随着不断更新,Git 变得越来越好用,越来越多的项目也开始使用 Git 做版本控制。

得益于 Linus Torvalds 的全世界程序员心中的男神的地位,不久之后,Git 迅速席卷整个开源社区,以Git 起家的 Github 轻松挤垮了 SVN 阵营的 Google Code

然而 Git 真的有这么好吗,使用 Git 一段时间之后,终于有了一些自己的体会。

Continue reading “Git 比 SVN 好在哪里?”