Detailed explanation of rebase examples for git learning

本篇文章给大家带来了关于Git的相关知识，其中主要介绍了rebase的相关问题，rebase，变基，可以直接理解为改变基底。feature分支是基于master分支的B拉出来的分支，feature的基底是B，希望对大家有帮助。

推荐学习：《Git学习教程》

本文用最简洁的例子让你快速掌握rebase原理和用法

一、提交节点图解

首先通过简单的提交节点图解感受一下rebase在干什么

两个分支master和feature，其中feature是在提交点B处从master上拉出的分支

master上有一个新提交M，feature上有两个新提交C和D

此时切换到feature分支上，执行如下命令，相当于是想要把master分支合并到feature分支（这一步的场景就可以类比为我们在自己的分支feature上开发了一段时间了，准备从主干master上拉一下最新改动）

git checkout featuregit rebase master

//这两条命令等价于git rebase master feature

下图为变基后的提交节点图，解释一下其工作原理：

• feature：待变基分支、当前分支
• master：基分支、目标分支

官方解释（如果觉得看不懂可以直接看下一段）：当执行rebase操作时，git会从两个分支的共同祖先开始提取待变基分支上的修改，然后将待变基分支指向基分支的最新提交，最后将刚才提取的修改应用到基分支的最新提交的后面。

结合例子解释：当在feature分支上执行git rebase master时，git会从master和featuer的共同祖先B开始提取feature分支上的修改，也就是C和D两个提交，先提取到。然后将feature分支指向master分支的最新提交上，也就是M。最后把提取的C和D接到M后面，但这个过程是删除原来的C和D，生成新的C’和D’，他们的提交内容一样，但commit id不同。feature自然最后也是指向D’。

通俗解释（重要！！）：rebase，变基，可以直接理解为改变基底。feature分支是基于master分支的B拉出来的分支，feature的基底是B。而master在B之后有新的提交，就相当于此时要用master上新的提交来作为feature分支的新基底。实际操作为把B之后feature的提交存下来，然后删掉原来这些提交，再找到master的最新提交位置，把存下来的提交再接上去（新节点新commit id），如此feature分支的基底就相当于变成了M而不是原来的B了。（注意，如果master上在B以后没有新提交，那么就还是用原来的B作为基，rebase操作相当于无效，此时和git merge就基本没区别了，差异只在于git merge会多一条记录Merge操作的提交记录）

上面的例子可抽象为如下实际工作场景：张三从B拉了代码进行开发，目前提交了两次，开发到D了；李四也从B拉出来开发了并且开发完毕，他提交到了M，然后合到主干上了。此时张三想拉下最新代码，于是他在feature分支上执行了git rebase master，即把master分支给rebase过来，由于李四更早开发完并合了主干，如此就相当于张三是基于李四的最新提交M进行的开发了。

---

二、实际git提交示例

按照上面的图解构造了提交记录，如下图所示：（ABM是master分支线，ABCD是feature分支线。这里画成了master变色分叉出来，这不影响理解，知道是表示两个分支两条线即可！）

此时，在feature分支上执行git rebase master

变基完成以后，ABCD是原来的feature分支线，ABMC’D’是新的feature分支线，ABM是master分支线（没有变化）

---

三、推荐使用场景

搞来搞去那么多，这其实是最重要的。不同公司，不同情况有不同使用场景，不过大部分情况推荐如下：

1. Use rebase when pulling the latest code from a public branch, that is, git pull -r or git pull --rebase, but one disadvantage is that after rebase, I don’t know which branch my current branch was first pulled from. It came out because the base has changed. (Because of this, most companies actually don't use rebase, and basically use merge. Although there will be a meaningless submission record "Merge... to...", at least they can know who did what)
2. When merging code into a public branch, use merge. (If you use rebase, then if other developers want to see the history of the main branch, it will not be the original history. The history has been tampered with by you. For example, Zhang San and Li Si pulled development from a common node. Zhang San completed the development first and submitted two Then the merge went up, and Li Si later developed and rebased it (note that Li Si needs to switch to the main branch, then execute git rebase, and then git pull to the remote end), then Li Si's new submission becomes Zhang San's new The new base submitted, originally Li Si’s submission was the latest, but the latest submission showed that it was Zhang San’s instead, and everything went wrong)

Recommended study: "Git Tutorial 》

The above is the detailed content of Detailed explanation of rebase examples for git learning. For more information, please follow other related articles on the PHP Chinese website!