---

layout: post

title: "Subversion 用户眼中的 Git (1): 集中式 vs 分布式"

---

“Git 很古怪” —— 使用 Subversion 的用户说道。

那么从 Subversion 用户的角度来看，Git有哪些古怪之处，或者说特别之处呢？

我们将会以连载的方式一一道来。

如果您有什么建议和补充，或者想知道 Subversion 中的某个 git 对应物，可以在博客后留言 ...oO

<h2>两种不同类型的版本库：集中式和分布式</h2>

<strong><span style="text-decoration: underline;">Subversion 属于集中式的版本控制系统：</span></strong>

<ul>

<li>每个版本库有唯一一个“官方地址”，每个用户都从这个唯一地址获取代码、数据；</li>

<li>获取代码库的更新，也只能连接到这个唯一的代码库，同步以取得最新数据；</li>

<li>提交必须有网络连接（非本地版本库）；</li>

<li>提交需要授权，如果没有授权，提交失败；</li>

<li>提交并非每次都能够成功。如果有其他人先于你提交，会提示“改动基于过时的版本，先更新再提交”... 诸如此类</li>

<li>冲突解决是一个提交速度的竞赛：手快者，先提交，平安无事；手慢者，后提交，可能遇到麻烦的冲突解决</li>

</ul>

<span style="text-decoration: underline;"><strong>Git 属于分布式的版本控制系统：</strong></span>

<ul>

<li>众生平等，每个检出(checkout)的版本库，或者更准确的说每个克隆(clone)的版本库都是平等的。

你可以从任何一个版本库的克隆来创建属于你自己的版本库，同时你的版本库也可以作为源提供给他人，只要你愿意。</li>

<li>获取版本库的更新，可以来自任何源。

你可以从张三那里获得上游的改动，包括张三自己的提交；你也可以从李四那里获得上游的改动，也可能包括李四的提交。</li>

<li>提交完全在本地完成。无须别人给你授权，你的版本库你作主。

当然你在你的版本库中的改动是否别人愿意合并到他们的版本库则是另外的一回事了。</li>

<li>提交总是会成功，因为提交是在本地进行的么。

甚至基于旧版本的改动也可以成功提交，提交会基于旧的版本创建一个新的分支</li>

<li>冲突解决不再像是SVN一样的提交竞赛，而是在需要的时候才进行合并和冲突解决

<ul>

<li>Subversion的提交竞赛，在多人协作开发时，提交经常被打断。坏的体验 :-(</li>

<li>Git 的每个用户就好像工作在独立的 Feature Branch （功能分支）中</li>

<li>Git的提交不会被打断，直到你的工作完全满意了，PUSH给他人或者他人PULL你的版本库

合并会发生在PULL和PUSH过程中，不能自动解决的冲突会提示您手工完成</li>

</ul>

</li>

</ul>

<strong><span style="text-decoration: underline;">Git 也可以模拟集中式的工作模式</span></strong>

<ul>

<li>Subversion只有一种集中式的工作模式

所有人都和服务器同步，提交直接到服务器上</li>

<li>Git 也可以模拟集中式的工作模式

<ul>

<li>Git版本库统一放在服务器中</li>

<li>可以为 Git 版本库进行授权：谁能创建版本库，谁能向版本库PUSH，谁能够读取（克隆）版本库</li>

<li>团队的成员先将服务器的版本库克隆到本地；并经常的从服务器的版本库拉（PULL）最新的更新；</li>

<li>团队的成员将自己的改动推（PUSH）到服务器的版本库中，当其他人和版本库同步（PULL）时，会自动获取改变</li>

</ul>

</li>

<li>Git 的集中式工作模式非常灵活

<ul>

<li>你完全可以在脱离Git服务器所在网络的情况下，如移动办公／出差时，照常使用代码库</li>

<li>你只需要在能够接入Git服务器所在网络时，PULL和PUSH即可完成和服务器同步以及提交</li>

<li>Git提供 rebase 命令，可以让你的改动看起来是基于最新的代码实现的改动</li>

</ul>

</li>

<li>Git 有更多的工作模式可以选择，远非 Subversion可比</li>

</ul>