上一次转载了介绍GitHub的博文点我，我想对于初学GitHub的同学们还是有不清楚的地方，毕竟有些概念的理解比较费力。我觉得作为一个对于配置库技术已经有一定基础的同学们，要学习GitHub，最快以及最能够深刻理解的就是和自己熟悉的一个配置库技术进行比对，分析优缺点。本文就比对下目前业界最流行的GitHub和老牌配置库技术Subversion。看看是老而弥坚还是初生牛犊不怕虎。
一、Subversion的特点
●每个版本库有唯一一个“官方地址”，每个用户都从这个唯一地址获取代码、数据;
●获取代码库的更新，也只能连接到这个唯一的代码库，同步以取得最新数据;
●提交必须有网络连接(非本地版本库);
●提交需要授权，如果没有授权，提交失败;
●提交并非每次都能够成功。如果有其他人先于你提交，会提示“改动基于过时的版本，先更新再提交”… 诸如此类;
冲突解决是一个提交速度的竞赛：手快者，先提交，平安无事;手慢者，后提交，可能遇到麻烦的冲突解决。
二、GitHub的特点
众生平等，每个检出(checkout)的版本库，或者更准确的说每个克隆(clone)的版本库都是平等的;
●你可以从任何一个版本库的克隆来创建属于你自己的版本库，同时你的版本库也可以作为源提供给他人，只要你愿意;
●获取版本库的更新，可以来自任何源;
●你可以从张三那里获得上游的改动，包括张三自己的提交;你也可以从李四那里获得上游的改动，也可能包括李四的提交;
●提交完全在本地完成。无须别人给你授权，你的版本库你作主;
●当然你在你的版本库中的改动是否别人愿意合并到他们的版本库则是另外的一回事了;
●提交总是会成功，因为提交是在本地进行的么;
●甚至基于旧版本的改动也可以成功提交，提交会基于旧的版本创建一个新的分支 ;
●冲突解决不再像是SVN一样的提交竞赛，而是在需要的时候才进行合并和冲突解决 ;
●Subversion的提交竞赛，在多人协作开发时，提交经常被打断;
●Git的每个用户就好像工作在独立的 Feature Branch(功能分支)中 ;
●Git的提交不会被打断，直到你的工作完全满意了，PUSH给他人或者他人PULL你的版本库;
●合并会发生在PULL和PUSH过程中，不能自动解决的冲突会提示您手工完成;
●Git也可以模拟集中式的工作模式;Subversion只有一种集中式的工作模式;
●所有人都和服务器同步，提交直接到服务器上;
●Git也可以模拟集中式的工作模式 ;
●Git版本库统一放在服务器中;
●可以为 Git 版本库进行授权：谁能创建版本库，谁能向版本库PUSH，谁能够读取(克隆)版本库;
●团队的成员先将服务器的版本库克隆到本地;并经常的从服务器的版本库拉(PULL)最新的更新;
●团队的成员将自己的改动推(PUSH)到服务器的版本库中，当其他人和版本库同步(PULL)时，会自动获取改变;
●Git 的集中式工作模式非常灵活;
●你完全可以在脱离Git服务器所在网络的情况下，如移动办公/出差时，照常使用代码库;
●你只需要在能够接入Git服务器所在网络时，PULL和PUSH即可完成和服务器同步以及提交;
●Git提供rebase命令，可以让你的改动看起来是基于最新的代码实现的改动;
●Git有更多的工作模式可以选择，远非 Subversion可比。
三、两种配置库技术的应用场景
经过上面的分析我们基本上可以看出来两种配置库技术优缺点了。那么在合适的场景使用合适的配置库技术来解决配置库管理的问题，才是我们的最终目的。
加入你的配置库管理了大量的二进制文件，例如excel、ppt、word等，由于这种文件无法合并，一旦出现冲突后，需要花大量时间来解决冲突。并且这种二进制
文件进行协同开发的可能性不高，那么推荐你还是使用Subversion。他的悲观锁的特性，能够帮助你保证二进制文件不会出现太多的合并问题。
如果你应用的场景是一个开源项目组，需要有更多的志愿者加入到项目中，希望营造一个开放，灵活的配置库环境。那么推荐你使用GitHub。它极低的拉分支
成本，分支自动合并。为每一个用户的分支提供平等的权限，保证用户在push变更到服务器之前，都不会因为其他人的修改出现冲突的问题。会让每一个开发人员
觉得协同起来非常爽。尤其是开发人员零散不是一个团队的时候，这一点就尤为重要。
至今为止有一点我始终还是有疑问，由于GitHub极低的分支成本，就有可能操作分支的个数超多，在进行合并时虽然能够保证自动合并不经常出现冲突。但是分支合并后是否会带来分支特性至今的逻辑冲突，对于这种冲突的识别是否只能够通过代码Review来控制风险。如何是这样的话，企业级别的应用对于GitHub配置库的应用就需要好好考虑一下了。
作者：yescoolfan
出处：http://www.cnblogs.com/yescoolfan
水平有限，欢迎指正，转载时请附上原文链接