什么是rebase
rebase, 译名”变基”. 要理解变基, 首先要理解什么是”基”.
大家都看过类似的 diff 页面, 右侧是变更后的文件, 与左侧的原始文件对比之后把其中的差异标注出来.
在这里, 左侧文件就是右侧的”base(基准)”, 右侧文件是”基于"左侧文件进行变更的.
在git中, 每个commit都是”基于”上一个commit做的变更, 那么变基就是, 原commit的指向到一个新的父commit. (当然因为父commit变化了, 那么子commit 也不是原来的commit了)
使用场景
git pull --rebase
一个项目由多个同事协同作业, 现在需要合进master中, 有同事已经把自己的代码先合进去了, 分支情况如下图所示
使用git pull 把代码拉下来, 会产生一个merge点, 在这里查看git log, 会看到c3, c4, c5, c6 是按照时间先后顺序排列的.
使用git pull —rebase 命令, 会把你的"mywork"分支里的每个提交(commit)取消掉，并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新 为最新的"origin"分支，最后把保存的这些补丁应用到"mywork"分支上。
这里被”变基”的commit 是c5和c6. 原c5 的父commit被指向了c4, 重新计算差异后产生了新的commit c5’, 原c6 的父commit被指向了c5', 重新计算差异后产生了新的commit c6’.
综上所述, 变基操作其实把本地分支的commit 一个个贴在了远端master 最新commit c4 的后面.
在拉代码的时候使用git pull —rebase, 可以保持线性的提交历史, 第二, 可以让commit按功能模块排列而不是时间顺序排列
推荐在同步远端分支的时候, 使用git pull —rebase.
git rebase -i HEAD~n
开发完功能后, 补充了多个 bugfix, 和 build 的commit, 直接合代码会让master变得混乱
解决方案: 使用git rebase -i HEAD~10 调整最近的十个commit. 把多个commit融合为少数的几个, 按实际情况决定是否保留commit message, 也可以在rebase时丢弃commit.
操作完之后, 在保持各个commit 提交内容的情况下, commit 数量就由10个 变成了两个, 使用git log看起来清爽了很多
