GIT 学习指导（6）

git成名的地方在于分布式版本管理。其中的关键技术是远程分支。开发者的本地作品，相对于另一个开发者就是一个远程分支（别人的远程分支也是自己的本地分支，都是相互相对的）。本地分支和远程分支并行演进。如下图所示：

上图中的origin/master显然是一个指针，指向了”上次“与远程仓库通信时，记忆的分支位置。虽然逻辑上，此时的origin/master应该指向y这个节点，但是如果本机不联网，无法感知这个位置的。我们可以通过联网通讯，把远程分支同步到本机，这样origin/master就可以前进到y这个位置了。所以origin/master是个特殊的指针，叫做远程跟踪分支指针。本机的分支指针master随着本机的commit等操作前进，origin/master只能通过远程传输相关操作前进。

“远程"这个词可以扩展一下，在git里，本机的另外一个文件夹存储另一份仓库数据，也可以认为是一个远程仓库。利用这一点，可以方便的在本机做远程分支的实验。

1）在C盘建立一个中心仓库（位于c:/aaa）
cd aaa
git init --bare  
2)  在D盘clone中心仓库（位于d:/aaa）
git clone file://c:/aaa
3）同时，我们D盘建立项目的初始文件，这里只有一个文件
cd d:/aaa
git add a.c
git commit -m "V1"
4) 把D盘的成果上传到C盘中心库
git push
5）在E盘，再克隆出另一个仓库，可以模拟2个开发者协作（D和E）
git clone file://c:/aaa
D开发者和E开发者，都获得完全一致的仓库状态。如下图：

 6) D盘开发者继续开发，提交一次，看到的本地视图如下：

7) E盘开发者继续开发，提交一次，看到的本地视图如下：

8）D盘开发者把工作成果上传
git push

9)  E盘开发者把工作成果上传，但是......
git push     
失败了，提示： ! [rejected]        master -> master (fetch first) 
系统检测出冲突，两个平行的开发分支必须解决合并问题！这是对的，越早合并越好，否则一个向南极开发，一个向北极开发，将越来越难合并。因此E盘开发者需要按错误提示所指示的，把远程分支同步到本地。

10) E盘开发者下载远程分支
git fetch
这样就可以得到D的工作成果，如下图：

 这个图是不是很熟悉？远程分支下载到本地，与前文的master和slave本地分支没有啥特殊之处了。我们选择用rebase命令合并这两个分支。
11）E盘开发者合并分支，解决冲突。
git rebase origin/master   #结果如下图

 现在的master就基于V2做了合并。这正是我们要的结果。上次在第9)步我们失败了，现在再执行上传就可以成功了。
12）E盘开发者重新上传
git push       #结果如下

讨论一下，origin/master这个指针前进的原因只能是push和fetch，就是与远程仓库传递数据时才前进。这时它与master分支最大的不同。
13） 现在回到D盘开发者，他还要把E的工作成功下载到本地才行。
git fetch    #结果如下：
 D盘开发者的master分支现在落后于orgin/master了。这里又可以总结出来，push，fetch不能影响本地分支master的位置。看来还是需要一步操作才行。

14）这是最后一步，D盘开发者让master合并到origin/master
git rebase origin/master
结果如下：

 （完）