PDF《Git 魔法》

他们希望能找到最近一个可以完成的游戏记 录.或者他们想比较两个旧版本间的差异,来估算某个特定玩家干了多少活. 查看旧版本的理由有很多,但检查的办法都是一样的.他们必须去中心服务器索要那个旧版本的记 录.需要的旧版本越多,和服务器的交互就越多. Git 是新一代的版本控制系统中的一员,它的特点是分布式的,广义上也可以被看作是一种中心 式系统.从主服务器下载时,玩家会得到所有保存的记录,而不仅是最新版.这看来,玩家们好像 把中心服务器做了个镜像. 最初的克隆操作可能比较费时,特别当存档有很长历史的时候,但从长远看这是值得的.一个显而 易见的好处是,当查看一个旧版本时,就不再需要和中心服务器通讯了. 一个误区 一个很常见的错误观念是,分布式系统不适合需要官方中心仓库的项目.这与事实并不相符.给谁 照相也不会偷走他们的灵魂.类似地,克隆主仓库并不降低它的重要性.

3 一般来说,一个中心版本控制系统能做的任何事,一个良好设计的分布式系统都能做得更好.网络 资源总要比本地资源耗费更昂贵.不过我们应该在稍后分析分布式方案的缺点,这样人们才不会按 照习惯做出错误的比较. 一个小项目或许只需要分布式系统提供的一小部分功能,但是,在项目很小的时候,就理应使用规 划并不好的系统?就好比说,在计算较小数目的时候应该使用罗马数字? 而且,你的项目的增长可能会超出你最初的预期.从一开始就使用 Git 好似带着一把瑞士军刀, 尽管你很多时候只是用它来开开瓶盖.某天你迫切需要一把改锥,你就会庆幸你所有的不单单是一 个启瓶器. 合并冲突 对于这个话题,电脑游戏的类比显得不够用.那让我们再来看看文档编辑的情况吧. 假设 Alice 在文档开头插入一行,并且 Bob 在文档末尾添加一行.他们都上传了他们的改动. 大多数系统将自动给出一个合理的处理方式:接受且合并他们的改动,这样 Alice 和Bob 两人 的改动都会生效. 现在假设 Alice 和Bob 对文件的同一行做了不同的改动.如果没有人工参与的话,这个冲突是 无法解决的.第二个人在上载文件时,会收到 合并冲突的通知,要么用一个人的改动覆盖另一个 的,要么完全修订这一行. 更复杂的情况也可能出现.版本控制系统自己........