极其方便的分支功能（而且是精明的在你本地开分支），让开发者很方便的在分支上开发，其背后的良苦用心在于借助分支帮大家 “降低冲突频率”。
极其方便的 rebase 和 merge 功能，在 “经常合并” 的思路下，既解放了 SCM ，又解放了开发者，其背后的深意实则是鼓励大家 “经常合并”。
这个时候，你应该能理解为什么大家都说 Git 洋气了吧？也大概能理解 Git 的一个历史演进过程了吧（咳咳，这个过程是我自己总结和理解的哈，反正我是这么理解的，也不知道对不对，管它呢，听起来还是能自圆其说的）
好，到这里，你估计不得不承认 Git 确实比 svn 更先进一些，不过你依然无法抵挡 svn 简单好用的诱惑，没关系，如果 Git 就此止步，那它顶多也就是个“略牛逼”的软件而已，掀不起什么风浪的。
基于 Git 有个叫 GitLab 的开源软件，已经被部署到了阿里，它才是利器。
GitLab如果说 svn 是软件，有了 GitLab 我们拥有的就是项服务了。
就像 Hadoop 是一个软件，阿里云是一项服务。
站在使用者的角度上来讲，服务显然要比软件来的方便的多得多，服务除了包含软件本身之外，还包含周边很多的东西，装逼的时候，我们通常管这些 “周边的东西” 叫「生态」。
不假大空，我们还是从身边活生生的例子来剖析，一个软件的生命周期，通常我们为了保证软件的质量会做这么几件事情：
code review
持续集成
需求管理
缺陷跟踪
在 svn 系里面，如果我们想要做 code review，我们得自己搭一个服务叫做 reviewboard（ rb 的确是一个值得尊敬的牛逼软件，但是我们得自己维护这玩意多少就有些不好玩了）
在 svn 系里面，如果我们想要做持续集成，我们得自己搭一个软件叫做 buildbot 或者 jekins（ buildbot 和 jekins 的确是值得尊敬的牛逼的软件，但是我们得自己维护这玩意多少就有些不好玩了）
在 svn 系里面，如果我们想要做需求管理，我们得自己搭一个软件叫做 jira 或者其他什么的（ jira 的确是一个值得尊敬的牛逼的软件，但是我们得自己维护这玩意多少就有些不好玩了）
在 svn 系里面，如果我们想要做缺陷管理，我们得自己搭一个软件叫做 bugfree 或者其他什么的（ bugfree 的确是一个值得尊敬的牛逼的软件，但是我们得自己维护这玩意多少就有些不好玩了）
我勒个去，等会等会，我平时还真没注意，一个 svn 周边要自建这么多东西啊？？？
------------------------------------------------
没错，这就是软件时代的玩法，嘿嘿，不过到了服务时代，完全就不一样了，GitLab 让你爽到没朋友。
以上所有的这些功能型软件，GitLab 全部包含，重要的是你不必跨多个系统去使用，在 GitLab 上，所有的事情全部一站搞定。
提供给程序员的服务，如果能够做到不转移、不分散他们的注意力，就是积了大德。
GitLab 做到了，一切以代码为核心，围绕在代码周边的是：需求（issue）、持续集成（gitlab-ci）、code-review（原生态天然自带功能，非常自然）等等
------------------------------------------------
一个有意思的现象是：程序员在 “需求管理平台”、“缺陷跟踪平台” 等这些平台上毫无热情，却在 GitLab 上能思维敏捷、口齿伶俐、口吐莲花、舌战群儒，为啥？
很简单，程序员离不开代码就好像农民离不开土地一样。
别装了，那是因为 GitLab 是一个社区，你在上面骚浪贱能引起关注、引发讨论，你在“需求管理平台”上写个万字长文看有人理你么。。。
好了，也不早了，这个万字长文也该发到 GitLab 上找找存在感了。
对了，最后，我们客观并且冷静的得出一个结论：Git 来了，可以让操劳了这么多年的 svn 休息休息了。
下回，考虑来一发技术流的文章，来好好扯一扯 svn 的命令和 Git 的命令，相信在这篇文章的基础之上，再去理解 Git 命令就没那么困难了。
更多GitLab相关教程见以下内容：
Ubuntu 14.04下安装GitLab指南