Git之变基方式Rebase的使用

Posted 2022-03-30 Serendipity·y

一、Rebase 产生意义

• 在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase。对应 merge 操作来说，想必我们都已经使用过很多次了，而 rebase 又是用在哪里呢？已经其正确的使用方式，到底是什么呢？
• 使用 Git 进行产品开发的代码管理，势必是会存在多人在同一个分支上协同工作的问题，这样就很容易出现冲突。而遇到冲突的时候，一般情况都是已经有人在该分支上面提交代码了，我们不得不先将其他的提交 pull 到本地，然后在本地合并(如果有冲突的话)，最后才能 push 成功。

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

• 但是我们会发现提交记录会变得有点乱，强迫症的你可能需要一条干净的直线，因为太多无用的 commit 很让人不舒服，而且不利于每天下午的 code review 代码检视，同时也会污染分支提交记录。
• 如果使用 rebase 操作的话，可以把本地未 push 的分叉提交历史整理成直线，rebase 的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

$ git log --graph --pretty=oneline --abbrev-commit
*   e0ea545 (HEAD -> master) Merge branch 'master' of github.com:xxx/xxx
|\\
| * f005ed4 (origin/master) add email info
* | 582d922 add author info
* | 8875536 add comment info
|/
* d1be385 init hello repo
......

二、Rebase 合并纪录

• rebase 会使原本分叉的提交立马变成一条直线，这种神奇的操作，其实原理非常简单。注意观察，Git 把我们本地的提交“挪动”了位置，放到了 f005ed4 之后，这样整个提交历史就成了一条直线。rebase 操作前后，最终的提交内容是一致的，但是，本地的 commit 修改内容已经变化，它们的修改不再基于 d1be385，而是基于 f005ed4，但最后的提交 7e61ed4 内容是一致的。

$ git rebase
First, rewinding head to replay your work on top of it...
Applying: add comment
Using index info to reconstruct a base tree...
M    hello.py
Falling back to patching base and 3-way merge...
Auto-merging hello.py
Applying: add author
Using index info to reconstruct a base tree...
M    hello.py
Falling back to patching base and 3-way merge...
Auto-merging hello.py

# 再用 git log 看看发现变成直线
$ git log --graph --pretty=oneline --abbrev-commit
* 7e61ed4 (HEAD -> master) add author info
* 3611cfe add comment info
* f005ed4 (origin/master) add email info
* d1be385 init hello repo
......

• 当然，也可以指定对最近的多少次的提交纪录进行合并。需要注意的是，不要合并已经提交到仓库的提交，不然会有问题。

选项列表	对应含义解释
p, pick	use commit
r, reword	use commit, but edit the commit message
e, edit	use commit, but stop for amending
s, squash	use commit, but meld into previous commit
f, fixup	like “squash”, but discard this commit’s log message
x, exec	run command (the rest of the line) using shell
d, drop	remove commit

# 合并最近的3次提交纪录
# 之后就会自动进入vi编辑模式
$ git rebase -i HEAD~3
s 7e61ed4 add author info
s 3611cfe add comment info
s f005ed4 add email info

# 最好编辑退出即可
# 如果你异常退出了vi窗口，不要紧张，执行下面操作即可
$ git rebase --edit-todo
$ git rebase --continue

三、Rebase 分支合并

• 假设我们团队一直在 master 分支上面开发，但是因为新功能所以切了一个 dev 分支出来。这时，同事完成了自己开发的部分 hotfix 并将其合入了 master 分支，此时我的分支已经落后于 master 分支。
• 恰巧，这时需要同步 master 分支上面的改动，进行测试，那么就需要 merge 代码到自己的分支上。此时，我们会发现本地有一些 merge 信息。可能你会认为这样会污染我们自己的原本干净的提交记录，想要保持一份干净的提交记录，此时，就使用 rebase。
• 使用 git rebase 命令，先回退到同事 hotfix，后合并 master 分支：
• • 首先，git 会把 dev 分支里面的每个 commit 取消掉；
• • 其次，把上面的操作临时保存成 patch 文件，存在 .git/rebase 目录下；
• • 然后，把dev 分支更新到最新的 master 分支；
• • 最后，把上面保存的 patch 文件应用到 dev 分支上；
• 从 commit 记录上可以看出来，dev 分支是基于 hotfix 合并后的 master，自然而然的成为了最领先的分支，而且没有 merge 的 commit 记录。

# 我们自己在dev分支上面
$ git rebase master

四、Rebase 使用建议

• 使用 rebase 当中需要注意的地方：
• • 最好是该分支只有你自己在使用，否则请谨慎操作。
• • 只使用 rebase 来清理本地的提交记录，千万不要尝试对已发布的提交进行操作。
• 虽然 rebase 相对于我们已知的整合操作来说有着比较显著的优点，但是这也是在很大程度上取决于个人的喜好。一些团队喜欢使用 rebase，而另一些可能倾向于使用 merge 合并。此外，rebase 相对于 merge 合并来说是比较复杂的，除非你和你的团队确定会用到 rebase 操作。