之前公司一直在用 svn，虽然我也有用 github，但并没有真正参与过多人开发的 情况，分布式的 git 在多人开发方面与 svn 有很多不同。
git 是完全并行的开发，意味着提交的时候，origin 远端只是看对应文件能否 merge，不不冲突的话就直接接受了。可是如果我们看版本线，会有这样的情况， 本地刚提交的版本的上一个版本，并不是远端的末端版本，也就是说，在我们这两 次提交的中间，其他人已经有版本提交到远端了。
如果用 source tree 这样的工具看，可以看到本地上个版本对应的远端版本，很 可能有多条线并行出来；先提交的同学，版本线在主线上，后提交的同学，版本线 被并行出来，在最后提交的版本上合并。
svn 呢，因为没有分布式的概念，因此只有一条开发线。
为了更明晰远端库的版本线问题，每次 push 到远端前，需要在本地分支上 rebase origin 分支，其实就是先找到本地跟远端版本的公共父节点，从这个点开 始，将远端的版本合并到本地分支，再将本地分支这个公共父节点版本后的代码， 一个个 apply 上去，之后再 push 到远端，这时候就只有一条线了。
因此，merge 仅仅在末端版本上合并代码，而 rebase 则会找到公共父节点，重整 版本线。
另外一种情况，是本地再多开分支，其中一个分支用来同步远端，这个时候，本地 的另外一个分支，提交的顺序是先提交到本地同步分支，同步分支再 push 到远端。
这个时候，如果要保证三个分支的末端版本一致，同步分支可以先 rebase 远端， 保证末端版本与远端一致，本地分支再 rebase 本地同步分支，本地分支版本线也 与远端一致了；之后，同步分支 merge 本地分支，再 push 到远端。
或者也可以这样，本地同步分支先 merge 本地分支，再 pull rebase 远端，再 push 到远端。不过这个时候，这个用来并行开发的本地分支，版本线跟远端很可 能已经不一样了，这个又要怎么整呢，:)
坑好多呀，因为之前不明白这些，请教了组里面的一位实习生大神，才终于弄懂了。