在讨论Git的协作模式的时候，思考一下，git的基因是分布式的多人协作任务流。区别于传统的流水线模式，worker在完成一个任务的时候，或多或少的依赖上一个工作的任务。这就大大阻塞的工作的效率。因为绝大多数情况下，你的任务是没必要依赖上一个环节的处理的。我的意思不是业务上的分离，而是在开发上，至少你在很多情况下，你简单的需要一个mock的data 就可以模拟你的依赖。

所以，Git有branch这个东西。

仔细想想，似乎是，worker在接收到一个任务后，单独的fork出一个完整的工作环境，在其上完成自己的工作，并且merge到主干上。在git上，这很容易实现：

 git branch fix-some-bug

这样就创建了一个分支，你所有的改变都在这个分支上，最后被合并到master上。

这样的模式有一个问题，这个问题在多人协作模式下很容易就凸现出来，即：

当多人修改同一个地方的时候，冲突（conflict）就出现了。你必须修复它才能够合并到master。

考虑到多人工作的场景，所有人的code都合并到master，这些code将引入新的bug，所以，某些分支是受到保护的，你必须经过容许后才能够合并到其中。

最简单的例子就是，所有的代码都需要一个良好的单元测试来保证功能的正确性，并且，在提交后经过一些core review 才能够合并到master 。甚至，只是一个PR，最终是否Accept，还需要看决策层（可以是一个有权限的人来Merge pull request)。

core review是这个工作模式产生的一个文化，它鼓励你分享你的code并且乐于接受批评。这样做不但保证code的质量，营造了一个open的工程文化，并且能有效刺激你的编程技能迅速提升。

但是，当事情越来越复杂的时候，一些事情的效率就变得很低了。比如，每一个developer都需要运行它的test cases ，找到一个人来review自己的code ，发送一个pull request给指定的人….

事情渐渐又变成低效且复杂了。这些事情不能自动化么？

自动运行我的测试，自动检测我的代码风格，自动化一切重复的工作…..

没错，这时候,持续集成（CI）该出场了。

你已经理解了CI是什么东西，它提供了一个构建流来持续不间断的进行project的迭代更新。

一个简单的CI的工作流是这样的：

当你push 到一个分支的时候，你的所有工作都已经完毕。CI将自动为了分配容器来运行你的测试。包括但不限于单元测试。

比如当你需要这样的场景：

首先，当你的push到某个分支的代码后，你需要它先自动运行test cases ，然后进行build期间，按照你的规则来进行一些列的构建工作，当一切都完成后，你希望自动部署到某个服务器上。

没错，这就是CI所做的工作。它提供了一个可配置的文件让你来描述究竟要怎么完成你的任务。

你的描述将转换成一个DevOps的Request，比如你需要一台服务器运行LAMP环境，并且安装了Mysql5.6 。这些都可以在CI里面作为一个环，其中类似申请服务器这种指令将转交给DevOps来执行。这时候，开发和部署形成了闭环。 开发完全无感知到这一切是怎么运作的。

所需要做的，只是工具文化和约定。

比如，在git commit 里面增加语义，来触发你所定义的事件。

或者在一个chat room里面进行chapOps。

BTW:

最近一段时间DevOps被重新提起来，这个很早就出现的词再一次进入了公众的视线。 什么是DevOps，似乎首先你想到这事运维干的事情，大概就是某个家伙比较懒，把一切能自动化的工作都自动化了。 是的，确实是这样的。