源代码管理工具在软件项目中已经是标准配置了,几乎每个软件项目都会应用到,可以说是最基础的项目开发工具。选择也很多,可以自己搭建源代码管理服务,也可以直接用网上托管的服务,例如 Github、Gitlab、BitBucket 等。
但同样是应用源代码管理工具,为什么有的团队就能做到代码质量高,随时能发布新版本,高效开发?而有的团队却不能做到高效开发,拿到的代码也不稳定,合并时冲突很多?
今天,我将带你了解一下源代码管理工具,以及如何才能应用好源代码管理工具,以保证代码质量稳定,协作高效。
源代码管理工具发展简史
源代码管理工具也叫版本控制系统,是保存文件多个版本的一种机制。每一次有人提交了修改,这个修改历史都会被版本控制系统记录下来。如下图所示,每一次对内容的修改,都会形成一个当前项目完整内容的快照。
(图片来源:《什么是版本控制?》)
源代码管理工具从诞生到现在已经有 40 多年的历史了,经历了四个阶段。
没有源代码管理工具的时代
早些年开发软件可没有我们这么幸运,在 1972 年之前都没有任何工具可以帮助我们做源代码管理。
这就意味着,当你开发时,必须要告知团队里的其他人,你正在对哪些文件进行编辑,好让他们不要操作相同的文件。当你花了很长时间完成你的修改后,可能这些文件早已经被团队里的其他开发成员修改或者删除了。
除了协作的问题,还有一个问题就是版本问题。没有源代码管理,你得经常性对项目的文件保存备份,很麻烦,而且还是一样有不少问题:
- 很难知道做了哪些修改,你可能需要挨个目录去查看文件修改时间;
- 对版本命名是一个很麻烦的事情,每次备份都得有一个名字;
- 很难知道两次备份之间,做了哪些修改。
本地版本管理
最早的版本控制系统是 SCCS(Source Code Control System),诞生于 1972 年,它实现了对单个文件保留多个版本,这就意味着你可以看到每一个文件的修改历史了。
后来又有了 RCS (Revision Control System),它具有更好的文件比较算法,通过登录同一台中央大型机,可以实现每个人签出自己的拷贝。
但这个阶段只能本机使用,而且一次只能修改一个文件,无法满足好多人协作的问题。
集中式版本管理
1986 年问世的 CVS(Concurrent Versions System)是第一个采用集中式的服务器来进行版本库的管理工作,所有文件和版本历史都放在服务端,每个用户通过客户端获取最新的代码,可以多个人编辑一个文件,并且能提交到服务器合并在一起。
再后来的 SVN(Subversion)则对 CVS 进行了很多优化,比如支持文件改名移动、全局版本号等,这些优化很大部分程度上解决了 CVS 存在的一些缺陷,所以在 2000 年后逐步取代了 CVS 成为主流的源代码管理工具。
(图片来源:How Version Control Systems Work)
不过,这类集中式源代码管理工具,过于依赖服务器,如果服务器出问题或者连不上,就没法用了,如果服务器损坏,所有的版本历史也会丢失。
分布式版本管理
分布式版本管理工具的典型代表就是 Git,分布式版本控制系统的整个代码库的副本都可以存储在用户的本地系统上,这样文件和版本控制操作变得非常容易,离线也可以操作,如果主存储库关闭或者删除,可以很容易从本地存储库恢复。
现在 Git 已经逐步替代了 SVN、CVS 等源代码管理工具,成为最主流