要理解Rebase变基的本质我们可以从字面意思、生活比喻和技术原理三个维度来拆解。1. 字面意思重新定义“起点”Base基底、起点、根基。Re-base更换基底或者说重新寻找出发点。在 Git 中您写的每一行代码、每一次 commit都是基于某一个历史节点Base做出来的。当您写代码时基底是 A。在您写代码的过程中同事往服务器推送了新代码 B。此时您的起点Base已经落后了。Rebase 的本质就是把您的修改“剪切”下来等服务器上最新的代码更新完之后再把您的修改“粘贴”到最新代码的后面。2. 一个形象的比喻写书假设您和同事正在共同写一本书你们都写到了第二章 (Commit A)。此时同事在服务器上提交了第三章-优化编译 (Commit B)。而您在本地也写了一个第三章-自己的修改 (Commit C)。现在面临冲突有两种解决办法办法①Merge合并把你们两个人的“第三章”强行揉在一起并自动生成一个叫作“合并了两个第三章”的第四章 (Commit D)。缺点书的目录会变得混乱多出了一个无意义的“合并章节”。办法②Rebase变基Git 走过来对您说“您先别急着提交您的第三章。我先把同事写的【第三章-优化编译】拿过来作为新的基础然后把您的修改当成第四章重新写在后面。”优点书的目录变成了极其干净的一条直线第二章→\rightarrow→同事写的第三章→\rightarrow→您写的第四章。3. 技术原理Git 在背后做了什么以下是git pull --rebase执行时的真实过程状态 1分叉了服务器同事提交了 DA - B - D本地您提交了 CA - B - CD (服务器最新) / A - B \ C (您本地的修改)状态 2执行 RebaseGit 悄悄把您的临时提交C存到临时缓冲区。Git 把您的本地分支重置到服务器最新的D节点。此时您本地的历史变成了A - B - D。Git 把刚才存起来的C尝试“贴”到D的后面。A - B - D - C (您的修改被重新贴在了 D 后面)如果在“贴”的过程中第3步发现 C 和 D 修改了同一个地方比如同一个 APK 文件Git 就会暂停报出冲突Conflict让您决定保留谁。4. 为什么在 Rebase 冲突时ours和theirs颠倒了这常常让很多人感到困惑但在理解了 Rebase 的原理后就很容易解释了在普通合并Merge中--ours我们的代表您本地的代码。--theirs他们的代表服务器别人的代码。在变基Rebase中由于 Git 是先把本地分支重置成服务器的代码作为新基底然后再把您的修改贴上去。当 Git 切换到服务器代码时Git 认为服务器的代码才是“当前分支我们的--ours”。准备贴上去的您本地的修改反而变成了“外来的临时补丁他们的--theirs”。所以--ours 服务器上的最新代码。--theirs 您本地写好、准备贴上去的代码。