Rebase

在上一节我们看到了,多人在同一个分支上协作时,很容易出现冲突。即使没有冲突,后push的童鞋不得不先pull,在本地合并,然后才能push成功。

每次合并再push后,分支变成了这样:

  1. $ git log --graph --pretty=oneline --abbrev-commit
  2. * d1be385 (HEAD -> master, origin/master) init hello
  3. * e5e69f1 Merge branch 'dev'
  4. |\
  5. | * 57c53ab (origin/dev, dev) fix env conflict
  6. | |\
  7. | | * 7a5e5dd add env
  8. | * | 7bd91f1 add new env
  9. | |/
  10. * | 12a631b merged bug fix 101
  11. |\ \
  12. | * | 4c805e2 fix bug 101
  13. |/ /
  14. * | e1e9c68 merge with no-ff
  15. |\ \
  16. | |/
  17. | * f52c633 add merge
  18. |/
  19. * cf810e4 conflict fixed

总之看上去很乱,有强迫症的童鞋会问:为什么Git的提交历史不能是一条干净的直线?

其实是可以做到的!

Git有一种称为rebase的操作,有人把它翻译成“变基”。

Rebase - 图1

先不要随意展开想象。我们还是从实际问题出发,看看怎么把分叉的提交变成直线。

在和远程分支同步后,我们对hello.py这个文件做了两次提交。用git log命令看看:

  1. $ git log --graph --pretty=oneline --abbrev-commit
  2. * 582d922 (HEAD -> master) add author
  3. * 8875536 add comment
  4. * d1be385 (origin/master) init hello
  5. * e5e69f1 Merge branch 'dev'
  6. |\
  7. | * 57c53ab (origin/dev, dev) fix env conflict
  8. | |\
  9. | | * 7a5e5dd add env
  10. | * | 7bd91f1 add new env
  11. ...

注意到Git用(HEAD -> master)(origin/master)标识出当前分支的HEAD和远程origin的位置分别是582d922 add authord1be385 init hello,本地分支比远程分支快两个提交。

现在我们尝试推送本地分支:

  1. $ git push origin master
  2. To github.com:michaelliao/learngit.git
  3. ! [rejected] master -> master (fetch first)
  4. error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
  5. hint: Updates were rejected because the remote contains work that you do
  6. hint: not have locally. This is usually caused by another repository pushing
  7. hint: to the same ref. You may want to first integrate the remote changes
  8. hint: (e.g., 'git pull ...') before pushing again.
  9. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

很不幸,失败了,这说明有人先于我们推送了远程分支。按照经验,先pull一下:

  1. $ git pull
  2. remote: Counting objects: 3, done.
  3. remote: Compressing objects: 100% (1/1), done.
  4. remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
  5. Unpacking objects: 100% (3/3), done.
  6. From github.com:michaelliao/learngit
  7. d1be385..f005ed4 master -> origin/master
  8. * [new tag] v1.0 -> v1.0
  9. Auto-merging hello.py
  10. Merge made by the 'recursive' strategy.
  11. hello.py | 1 +
  12. 1 file changed, 1 insertion(+)

再用git status看看状态:

  1. $ git status
  2. On branch master
  3. Your branch is ahead of 'origin/master' by 3 commits.
  4. (use "git push" to publish your local commits)
  5. nothing to commit, working tree clean

加上刚才合并的提交,现在我们本地分支比远程分支超前3个提交。

git log看看:

  1. $ git log --graph --pretty=oneline --abbrev-commit
  2. * e0ea545 (HEAD -> master) Merge branch 'master' of github.com:michaelliao/learngit
  3. |\
  4. | * f005ed4 (origin/master) set exit=1
  5. * | 582d922 add author
  6. * | 8875536 add comment
  7. |/
  8. * d1be385 init hello
  9. ...

对强迫症童鞋来说,现在事情有点不对头,提交历史分叉了。如果现在把本地分支push到远程,有没有问题?

有!

什么问题?

不好看!

有没有解决方法?

有!

这个时候,rebase就派上了用场。我们输入命令git rebase试试:

  1. $ git rebase
  2. First, rewinding head to replay your work on top of it...
  3. Applying: add comment
  4. Using index info to reconstruct a base tree...
  5. M hello.py
  6. Falling back to patching base and 3-way merge...
  7. Auto-merging hello.py
  8. Applying: add author
  9. Using index info to reconstruct a base tree...
  10. M hello.py
  11. Falling back to patching base and 3-way merge...
  12. Auto-merging hello.py

输出了一大堆操作,到底是啥效果?再用git log看看:

  1. $ git log --graph --pretty=oneline --abbrev-commit
  2. * 7e61ed4 (HEAD -> master) add author
  3. * 3611cfe add comment
  4. * f005ed4 (origin/master) set exit=1
  5. * d1be385 init hello
  6. ...

原本分叉的提交现在变成一条直线了!这种神奇的操作是怎么实现的?其实原理非常简单。我们注意观察,发现Git把我们本地的提交“挪动”了位置,放到了f005ed4 (origin/master) set exit=1之后,这样,整个提交历史就成了一条直线。rebase操作前后,最终的提交内容是一致的,但是,我们本地的commit修改内容已经变化了,它们的修改不再基于d1be385 init hello,而是基于f005ed4 (origin/master) set exit=1,但最后的提交7e61ed4内容是一致的。

这就是rebase操作的特点:把分叉的提交历史“整理”成一条直线,看上去更直观。缺点是本地的分叉提交已经被修改过了。

最后,通过push操作把本地分支推送到远程:

  1. Mac:~/learngit michael$ git push origin master
  2. Counting objects: 6, done.
  3. Delta compression using up to 4 threads.
  4. Compressing objects: 100% (5/5), done.
  5. Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done.
  6. Total 6 (delta 2), reused 0 (delta 0)
  7. remote: Resolving deltas: 100% (2/2), completed with 1 local object.
  8. To github.com:michaelliao/learngit.git
  9. f005ed4..7e61ed4 master -> master

再用git log看看效果:

  1. $ git log --graph --pretty=oneline --abbrev-commit
  2. * 7e61ed4 (HEAD -> master, origin/master) add author
  3. * 3611cfe add comment
  4. * f005ed4 set exit=1
  5. * d1be385 init hello
  6. ...

远程分支的提交历史也是一条直线。

小结

  • rebase操作可以把本地未push的分叉提交历史整理成直线;

  • rebase的目的是使得我们在查看历史提交的变化时更容易,因为分叉的提交需要三方对比。

读后有收获可以支付宝请作者喝咖啡:

Rebase - 图2