一、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 'git@github.com: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 操作。
文章来源地址https://www.toymoban.com/news/detail-403868.html
文章来源:https://www.toymoban.com/news/detail-403868.html
到了这里,关于Git之变基方式Rebase的使用的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!