大话 Git 工作流

原文： https://blog.coding.net/blog/git-workflow
作者：wzw@Coding

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

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

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

小刘率先发言， 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 工作流。