git rebase的原理之多人合作分支管理

在上篇的Git rebase -i 交互变基，体验艺术般的命令文章中，我有两点为忽略了，现在补充说明下

1、在git rebase -i 后 ，用git push -f origin local_branch:remote_branch ：

其实这个命令在你一个人单独维护一个分支，不共享给其他人的时候 ，是可以随便用的，因为你一个人在本地就能确定哪个是你想要的，哪个你不想要。 而当你和其他人合作的时候，这个命令就不要用了，因为你会覆盖其他人的提交的，因为你用的命令是强制性覆盖。那么在多人合作时候，我们就应该学会git rebase的原理以及用法了，下面会讲述这个问题。

2、在git rebase -i遇到冲突了怎么办。

系统会提示你解决冲突后，用git add，然后继续用git rebase --continue完成后面的变基操作，并且还提示你，如果你不想用这次的git rebase -i操作，可以 用git rebase --abort来取消这次的操作，其实从这里可以看到git 很人性化的一面，前提是你要细心看懂这些提示。

好了，前话就说这么多，项目管理中一般会遇到很多问题，今天呢，要说的是git rebase 的原理 ，以及如何在项目中使用。

我相信大家在网上看到很我git rebase master的命令，告诉你这是什么意思 ，那么具体如何在项目上应用就很少有人说，首先，我自己来画副图玩玩，画不好见谅。

OK，master是喜闻乐见的远程分支，dev_branch那就是自己的分支了，有个人在维护远程分支 ，而我在维护dev_branch分支 ，那么这个时候需要master的修改，这个时候，一般我们会选择merge，因为master是我的基础分支，但是merge呢，就会出现很多人觉得不喜欢的一点，他会出现一个merge commit message，这让自己的分支看起来很不美观（不上图了，自己看不下去自己的画图了），那么这个时候，你可以选择git rebase orgin master。

git rebase origin master，这个命令可能跟网上不同，我加上了origin，那么这是什么意思呢，意思就是  我在本地的分支 dev_branch上， 对远程仓库（默认origin代表远程仓库）的master使用变基拣选操作。 如果我用git rebase master，就是对本地的master分支进行rebase ，前提是你需要git fetch origin来更新本地的分支，可能这样说大家有疑惑，那么上一张图

哎，自己画图的功底太渣了，还是动手解释吧。

我们用git branch可以查看到自己当前分支是dev_branch分支，那么使用git rebase origin master

git 会检测两个分支 dev_branch origin/master的公共parent 节点，很显然是B，这样我们的当前分支dev_branch和origin/master分支的节点的差异就是D了，或者更多，这个时候git 会把差异提交一个个拣选上去，就成了 D' ，注意不是D，相当于cherry-pick，但是呢 commitId改变 了，这个时候你就不会看到git merger的时候那个渣渣merge commit message了。

好了，当我们在自己的私有的分支上面这么操作的时候 ，会把自己的分支搞得很“干净”，很赏心悦目，那么这个时候问题来了，如果两个从共同维护一个分支 ，我们如何把分支也管理这么漂亮呢，好，下面开搞这个问题，又到了画图的时候，XXXX~

基础分支master，两个人分别对应的分支为dev_branch_S01（开发者S01） 和dev_branch_S02（开发者S02），可以看到这个时候 ，两个 人现在都在自己的分支上提交 了一个commit。

我们来假想下，如果S02 push了分支到master上去了，那么就是Fast-Forward，俗称快进式提交，有人会问什么叫快进式提交，哎，难解释 ，就我的理解就是，master的HEAD指针可以做简单的向前移动，具体细节搜搜吧，通俗点master所有提交都是dev_branch_s00的父节点，因此可以快进式提交。

而当S02提交完了后，S01开始push了，S01突然发现 ，尼玛，为什么我的提交被reject了，提示的是非快进式的提交 ，这个时候经过沟通了解到S02 push过了，所以S01会想到先git fetch 后 merge ，也就是git pull orgin master ( = git fech origin master && git merge origin/master),然后现提交 ，这个时候 ，万恶的merge commit message信息就来了。 但是我们今天就是解决这个问题。

刚才我们讲了git rebase master的原理，那么这个时候在dev_branch_S01分支上先git fetch origin，然后用git pull --rebase origin master来执行变基操作

这个时候，你应该发现了，master所有的提交在dev_branch_S01上都有了，这样就终于可以尼到的快进式的提交了，是不是很爽歪歪~