因为各种原因，国内社交平台有关 Git 和其他版本管理工具的口水战一直没停，因为版本控制是必备需求，所以程序员热衷就此表达自己的看法：

无论是自己写代码还是在企业工作，版本控制都是程序员的必备技能。经过多年发展，现在使用比较广泛的版本控制工具有 Git、SVN、Perforce、Hg、TFS 等。可能是由于 Github 和 Linus 的原因，Git 成为主流分布式版本控制系统，但国内不乏还在使用 SVN 的大型互联网企业。在这种情况下，程序员有必要花时间学习 Git 吗？

Git 与 SVN 对比

虽然有很多版本控制工具，但 SVN 和 Git 是使用范围最广泛的集中式和分布式工具代表。就个人开发者而言，不会使用 Git 意味着无法充分利用 Github 这个全球最大的开源网站，当然，个人通常不会选择商业化版本控制工具。在这种背景下，如果所在公司使用 SVN，个人程序员是否有必要花时间自学 Git 呢？

当然，可能会有人质疑：2019 年都到了，还有公司在使用 SVN 吗？答案是不仅有，而且不少，比如腾讯。说到底，Git 和 SVN 不过是一个版本控制管理工具，并没有哪个一定更好的说法，甚至个别程序员不过是把 Git 当做 SVN 在用。

SVN 是集中式版本控制系统的代表，其版本库集中存放在中央服务器，程序员使用个人电脑从中央服务器获取最新版本，并将更新后版本推送到中央服务器。集中式版本控制系统的通病是必须联网才可以工作，如果是局域网还好，带宽够大，速度够快；如果是互联网且网速较慢的话，提交一个 10M 文件可能就需要 5 分钟。当然，出于安全等多方面因素考虑，企业内部有自己的局域网很正常。

Git 是分布式版本控制的代表，没有明确的中央服务器概念，每个程序员的电脑上都有完整的版本库，只需要将更改互相推送给对方即可。一旦其中某个版本丢失，只需要从其他电脑上复制一份即可，相当于互相备份的概念。

相比 SVN，Git 的最大优势可能是分支管理，这非常契合开源项目的需求，但不少使用 Git 的程序员没有最大限度利用这一优势，国内程序员对开源社区的贡献也相对较低。SVN 的主要优势是目录级别权限控制，可以 Checkout 子目录，方便公司或团队管理，不少云供应商也提供云端的 SVN 相关工具。

SVN 与 Git 的使用场景本身不尽相同，因此并不存在高低之分。但就现状而言，程序员与开源项目的接触越来越多，企业也越来越喜欢使用开源项目，即便公司内部使用 SVN，但 Git 也会成为程序员的一项必备技能，毕竟在 Github 上互相交流是需要的，但 Git 在实际使用中还是存在很多问题。

Git 存在的问题

Git 本身的复杂性就不在此赘述，基础入门可能只需要简单培训，但要想熟练使用并挖掘最大优势着实需要费一番功夫，即便是 Git 专家也不会轻易推荐程序员使用 Git 作为入门工具，很多经验丰富的程序员使用 Git 时也需要查看帮助。OOPSLA16 有一篇论文专门分析了 Git 的问题，MIT 计算机科学和人工智能实验室的研究团队设计了一款叫做 Gitless 的新工具，感兴趣的可以自行搜索。

在存放巨型项目、大型二进制文件以及嵌套方面，Git 一直存在问题。GVFS、Git LFS 倒是可以解决现阶段的部分问题，但性能和生态支持还不足够。此外，Git 的概念是比较清楚的，但指令非常混乱，Git 没有中央控制服务器，GitHub 和本地 Git 库平等，没有针对目录和文件夹的权限控制。由于两边对等，所以 push、pull、remote branch 这些概念其实很麻烦，用起来也不方便。

只能说，Git 目前确实存在一些问题，但这些问题不影响程序员的常规使用。反之，如果只是把 Git 当做 SVN 用，并没有发挥 Git 的优势。

总结

通过社交平台的言论对比，大部分程序员认为即便公司使用其他版本控制工具，个人还是很有必要学习 Git，毕竟使用开源项目难免需要在社区交流探讨问题。但是，无论选择哪款工具都没有高低贵贱之分，使用 SVN 也不代表落后；其次，Git 目前的支持越来越完善，周边生态也逐渐强大，已经成为主流选择，出于日后的职业发展考虑，程序员起码应该先行入门 Git。