SVN集中式版本管理工具

　　SVN能干嘛?

　　为了能够更好的记录保留软件开发过程中的迭代版本，

　　你每一次修改后提交的代码，SVN服务器都为我们保留了记录。

　　为了能够更好的协同开发，并有效的解决多人之间的冲突，

　　多个人修改一个文件，把不同的修改进行合并，这解决了我们协同开发中的一大难题。

　　为了能够更便捷的异地同步代码，

　　手机、平板、家里电脑、公司电脑，跟今天的云盘一个道理。

　　于是诞生了版本管理工具。SVN便是其中比较流行的一个工具。

　　这是一个集中式的版本管理，所有的数据都经过中央服务器进行交换同步

　　Git 分布式版本管理工具

　　git能干嘛?

　　功能上跟SVN一样，只不过它是分布式的，不存在中央服务器

　　乍看上去，好像灰常复杂，其实不然。就是说根本没有服务器的概念，或者人人都是服务器。任意两台电脑都可以互相通信

　　但是这样带来一个问题，就是如果要同步代码，至少要保证两台机器同时开机，所以使用git的通常做法是这样的：

　　后来有了github这个神奇的网站，它提供24小时不间断的服务，并且在github上提交的代码可以公开分享，来自全球的小伙伴学习别人的代码更加的方便了，并且还是以版本管理的方式来同步代码。于是git就瞬间流行起来了。

　　但是由于git复杂的原理，让它的学习成本比svn高出了很多倍。非常不适合初学者

　　接下来，我尝试用图解的方式讲解git原理，让大家弄明白，git 为什么会看起来比SVN复杂很多却又很受欢迎。

　　但不同的是，github自己编写了一套程序接口，你可以通过在它的网站上注册，然后在github上建立属于你自己的仓库，然后把代码同步过去，注意我用了同步这个词，不是提交，因为大家一定要记住，这是分布式的!!

　　就是说github只是众多客户端之一(虽然它有点特殊)，这里没有服务器和客户端的概念。

　　(请注意，git是一个分布式版本管理软件，github是一个网站平台，请不要把二者混为一谈)

　　这样一来，大家就可以直接从github上下载，修改后都向github上面提交，就方便多了

　　讲到这里，你一定会有疑问，这跟SVN有什么区别?SVN貌似不用这么折腾吧?

　　第一，这跟SVN确实没什么区别。

　　但是，如果github网站挂掉了，张三、李四、王五仍然可以直接互相同步代码，SVN做的到吗?

　　第二，这个要重点说，git不单单只有这一点好处，更大的好处，在于它和SVN有着不同的管理文件的方式。

　　一个软件从建立，到最后发布上线，如果把每一次提交都算上，你觉得它大概要经历几万个版本?

　　我们都知道版本管理最大的好处就是可以保留我们的历史版本，在代码开发到一半的时候，不至于无故丢失，还可以查看BUG的来龙去脉。

　　那怎么样做到这一点呢?

　　如果每一次修改，都保留一个文件副本，那需要多少硬盘才能装的下?

　　SVN是集中式管理，大家把文件都提交到一个地方，这服务器的存储压力就大了去了。

　　因此它对于文件的版本控制，采用增量式的，只记录修改部分，不产生多余的数据。

　　但是要知道，只记录修改，不产生冗余，还得准确的还原每一个版本，解决冲突，可真不是一件容易的事情

　　所以你就明白，为什么到现在SVN还是动不动一个误操作就出现无法提交的错误，BUG满天飞。

　　我们不得不说，SVN是一个非常优秀的版本管理软件，如果它早一点发明分支结构，如果在github之前就出现了svnhub，也许.....

　　算了，不提往事了，接下来再说git管理文件的方式。

　　Git以文件快照的方式保存，也就是说，每一个版本，就是一个文件副本

　　当然，对于没有变动的提交，git会自动生成一个虚的索引，就像快捷方式，以便节省空间，

　　但即便是这样，你肯定还是觉得，这种做法太浪费空间了。所以才发明了分支(fork)

　　我们还拿github举例子，现在它既然要变成一个类似服务器的角色，为所有人提供代码托管。

　　那如何来解决如此大量的冗余呢? 那就是想办法把冗余放到本地。

　　首先，我们从github上的项目克隆一份到我们本地，

　　我们把github上的项目称为主干，我们自己的称为分支，我们的修改只提交在本地。

　　等到版本稳定的时候，或者我负责的模块开发完成了，再把最后的版本提交到远程仓库。

　　这个过程称为分支的合并

　　当然，能不能合并，还得创建项目的人说了算。

　　试想一下，你发起了一个开源项目1.0，无数的人来帮你续写2.0版本，并向你发送了合并申请。

　　你挨个审查，挑了一个最优秀的合并到你的项目中，岂不是很爽?