集中式版本控制工具
而版本控制工具其实有两种,一种就是今天谈到的Git这种分布式版本控制工具，而另外一种就是SVN这种集中式版本控制工具。SVN的大名可能很多人都听说过，集中式这个词其实已经可以体现这种版本控制工具的缺点，集中式版本控制工具必须联网才能使用，而且版本库都有一个单一的集中管理的服务器，用于管理所有文件的所有修改版本，我们工作之前需要先从中央服务器取得最新的版本，然后进行修改，当我们修改完成之后，肯定要将我们的更新回传到SVN进行更新版本库。这时候如果有其他同事先于你之前更新，可能会报错：改动基于过时的版本，先更新再提交。所以说使用SVN这类集中式版本控制工具会导致一个问题：先完成工作的先更新不会出现问题，后完成工作的还得处理旧版本导致的代码冲突问题。这些都是SVN的缺点所在，但是SVN这类集中式版本控制工具最致命的缺点在于如果集中管理版本库的中央服务器出现问题，而又没有及时备份，有可能导致丢失整个项目的所有历史更改记录。
分布式版本控制工具
说完了集中式版本控制工具，接下来我们说说分布式版本控制工具。分布式版本控制工具最为流行的就是Git。分布式版本控制工具可以在每个人的电脑中创建一个完整的版本库，因此分布式版本控制工具集中不需要存在一台统一管理版本库的服务器。那我们针对刚才说过的SVN的缺点来说明为什么我们要采用Git。
Git如何协同合作
刚才说过集中式版本控制工具必须联网才能使用，而且版本库都有一个单一的集中管理的服务器，用于管理所有文件的所有修改版本，但是Git实际上在本地磁盘就保存着项目的所有历史更新版本，而且由于Git大部分都是操作本地资源所以完全不需要联网操作。Git其实一般也会存在一台电脑充当中央服务器的功能，但是实际上这台中央服务器不是用于统一管理版本库，而是用于同事之间交换修改使用。比如你将你的版本库提交到中央服务器，你的同事想要同步你的代码只需要将中央服务器的版本库pull下来与本地代码进行合并就可以，当同事工作完成上传中央服务器，我们也只需要pull代码进行合并，就可以在同事间很轻松的实现版本库的同步。刚才说到SVN有一个缺点：先完成工作的同事先更新不会出现问题，后完成工作的同事还得处理旧版本导致的代码冲突问题。但是在Git中不会出现这种提交竞赛，不同同事可以依次提交自己更新的部分，就算使用的版本库已经是旧版的一样可以上传，会在使用的旧版本的基础上新开一个分支，然后每次更新都会更新到这个分支，到某一天这个功能完全实现了，然后将几个同事开发的几个分支合并到主分支就可以进行合并代码。我们举个例子解释下：比如有三个同事同事基于某个v1.0.0版本开发，A同事更新代码后更新成功，B同事更新代码，由于A已经更新了版本，所以这时候我们可以有两个选择，第一种就是钢刺啊说的pull代码与本地代码合并再提交，或者这时候由于各自负责的功能还在开发，我们可以在这个v1.0.0的版本上创建一个新的分支，进行版本的更新迭代。一个月后整个功能完成了，这时候我们就可以合并三个同事的三个分支成为一个分支。
Git如何让做好备份工作
我们刚才一直在说Git在本地创建版本库，那版本库存储在本地磁盘，本地磁盘出问题我的所有版本库不就直接全部丢失了。我们可以这样操作：比如在D盘创建一个版本库，然后在F盘创建一个备份版本库，每次提交push到备份版本库，就可以实现版本库备份。
Git的优势
Git 和 Svn 的分支实现机制完全的不同，这也直接导致了 SVN 在分支合并中困难重重。当我们使用SVN中在一个分支上工作数周或几个月之后，主干的修改也同时在进行着，两条线的开发会区别巨大，当你想合并分支回主干，可能因为太多冲突，已经无法轻易合并你的分支和主干的修改。而在 git 版本库中创建分支的成本几乎为零，所以可以创建一个属于自己的个人工作分支，以避免对主分支 master 造成太多的干扰，也方便与他人交流协作。当最后功能完成最后需要合并分支来合并别人修改的时候，最好创建一个临时的分支用来合并，合并完成再fatch到自己的分支。
Git的缺点
中文完整的Git学习资料较少。
学习周期比较长。
代码一经pull，就可以完全公开源码和版本信息。
本文分享自微信公众号 - 程序猿周先森（zhanyue_org）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。