为dminorstudio引入新的项目管理系统GitLab（上）

2016/07/11

从2005年诞生至今，Git在软件开发领域早已不是一个新鲜的事物了，但直到半年前，我们对这个领域还是非常陌生的。这一方面是因为dminorstudio一直非常谨慎地控制团队的增长，以致协作开发和版本控制的需求一直没有真正凸显出来（我们一直在用Trello做为团队协作平台，用donedone作为问题追踪平台）；另一方面，也是更主要的原因还是，作为技术团队领头人的我，对Git庞大而复杂的结构望而生畏，以致一直止步不前。总之，在经历了几次代码管理混乱的痛苦之后，我们还是决定痛定思痛，要引入Git来管理我们的代码和项目开发了。

所以这篇文章（以及它的后续文章）与其说是经验分享，倒不如说是我们学习过程的一个记录和总结。简而言之，就是现学现卖了。所以不足之处，还请读者不吝赐教。

版本控制系统和Git

在电子编辑时代，任何存储在可擦写设备上的数据都是可自由更改的，而且一旦更改被保存，便无任何踪迹可循。这造成了很多问题：比如不同版本的文件在不同用户不同设备上的拷贝很难管理（版本众多时尤其如此），团队协作时会发生自己的更改被他人覆盖等等。这些问题都是版本控制系统需要解决的。

比如，为了解决版本众多的问题，可以给每一次确定的更改编上唯一的编号，即产生一个版次（Revision），并记录各个版次的先后顺序，从而形成变更历史。历史可以回滚和还原，以便将文件恢复到任何一个已记录的状态（版次）下。

而为了解决团队协作的问题，一个自然的解决方法是给正在被更改的文件上锁，由管理员集中分配权限，以保证同一时间只有一个人在更改同一个文件。采用这种方式工作的版本控制系统叫做中央式版本控制系统（Centralized Version Control System）。这类系统典型的有大名鼎鼎的Concurrent Versions System（CVS）和Subversion（SVN）。

中央式版本控制系统要求所有参与者必须随时联网，而且由于同一时间只能有一个人在更改一个文件，团队协作的优势难以体现。所以一个更好的方法是，让参与者在主版本的基础上产生一个分支和本地拷贝，每个人可以自由更改自己的本地拷贝，并将更改提交到自己的分支，最终将自己的分支合并到主分支。只有在分支和分支之间存在冲突（比如多个人同时更改了同一行代码）的情况下才需要手工处理，否则系统负责自动合并各个分支。采用这种方式的版本控制系统叫做分布式版本控制系统（Distributed Version Control System）。最终，经过一段时间的淘洗，Git在多个同类产品中脱颖而出，成为今天应用最广泛的分布式版本控制系统。

220px-Revision_controlled_project_visualization-2010-24-02.svg_.png

分布式版本控制系统
（图片来源：Wikipedia.org）

各种Git产品比较

目前Git标准的制定团队发布的协议有local、http、ssh和git四种，除了第一种，后面三者都需要有运行Git服务进程的服务器做支持。

迄今为止，提供Git产品或服务平台（或两者兼有）的公司已经不在少数了，而且大部分Git产品都是开源的，这意味着你可以将它获取过来，安装架设在自己的服务器上。经过多年的发展和演进，Git服务平台逐渐形成了包含：Git核心（即分布式版本控制）功能，问题追踪（Issue Tracking）、里程碑（Mile Stones）、知识库（Wiki）等等一系列功能在内的综合性的软件开发项目管理系统。

GitHub

GitHub可以说是目前最权威、最正宗、也是应用最广泛的Git系统，主要功能是提供代码库托管服务。一些重量级的客户（如Ruby on Rails、jQuery、twitter bootstrap、NASA等）的入驻，使得GitHub声名大振，稳坐于行业老大的位置。GitHub上面海量的用户和项目使得它还兼具社交和推广的功能，很多公司和个人在上面发布和推广自己的软件产品、承接项目、或是笼络优秀的同行。目前几乎所有Git服务平台提供的功能都或多或少受益于GitHub的不断创新和发展，GitHub为Git世界的贡献是无人可替代的。