Subversion用户眼中的用户眼中的Git
目录：
Subversion 用户眼中的 Git (1): 集中式 vs 分布式
Subversion 用户眼中的 Git (2): 版本库, 工作区如影随形
Subversion 用户眼中的 Git (3): 命令集不兼容
Subversion 用户眼中的 Git (4): 全局版本号和全球版本号
Subversion 用户眼中的 Git (5): 没有部分检出
Subversion 用户眼中的 Git (6): stage
Subversion 用户眼中的 Git (7): 完全不同的分支和里程碑的实现
Subversion 用户眼中的 Git (8): SVN没有后悔药，git有好多
Subversion 用户眼中的 Git (9): 单亲 VS 多亲
Subversion 用户眼中的 Git (10): Git 命令行的人性化设计
Subversion用户眼中的 Git (1): 集中式 vs 分布式
“Git 很古怪” —— 使用 Subversion 的用户说道。 那么从 Subversion 用户的角度来看，Git有哪些古怪之处，或者说特别之处
呢？ 我们将会以连载的方式一一道来。 如果您有什么建议和补充，或者想知道 Subversion 中的某个 git 对应物，可以在博客
后留言 …oO Subversion 属于集中式的版本控制系统： ?每个版本库有唯一一个“官方地址”，每个用户都从这个唯一地址获取
代码、数据；
获取代码库的更新，也只能连接到这个唯一的代码库，同步以取得最新数据；
提交必须有网络连接（非本地版本库）；
提交需要授权，如果没有授权，提交失败；
提交并非每次都能够成功。如果有其他人先于你提交，会提示“改动基于过时的版本，先更新再提交”… 诸如此类
冲突解决是一个提交速度的竞赛：手快者，先提交，平安无事；手慢者，后提交，可能遇到麻烦的冲突解决
Git 属于分布式的版本控制系统：
众生平等，每个检出(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可比
Subversion 用户眼中的 Git (2): 版本库, 工作区如影随形
Subversion 的工作区和版本库截然分开，工作区中的修改要提交到版本库，可能是本机另外一个目录的版本库，也可能是通
剩余7页未读，继续阅读
资源评论
