Detaillierte Erläuterung der Rebase-Beispiele für Git-Lernen

本篇文章给大家带来了关于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. Wenn Sie den neuesten Code aus einem öffentlichen Zweig abrufen, verwenden Sie Rebase, also git pull -r oder git pull --rebase. Ein Nachteil besteht jedoch darin, dass ich nach dem Rebase nicht weiß, welcher Zweig mein aktueller Zweig zuerst gezogen wurde von. Weil sich die Basis geändert hat. (Aus diesem Grund verwenden die meisten Unternehmen tatsächlich kein Rebase und verwenden grundsätzlich Merge. Obwohl es einen bedeutungslosen Einreichungsdatensatz „Merge… to…“ geben wird, können sie zumindest wissen, wer was getan hat)
2. Beim Zusammenführen von Code in einen öffentlichen Code Zweig, verwenden Sie Merge. (Wenn Sie Rebase verwenden und andere Entwickler den Verlauf des Hauptzweigs sehen möchten, ist dies nicht der ursprüngliche Verlauf. Der Verlauf wurde von Ihnen manipuliert. Beispielsweise haben Zhang San und Li Si die Entwicklung aus einem gemeinsamen Zweig gezogen Zhang San hat die Entwicklung zuerst abgeschlossen und zwei eingereicht. Dann wurde die Zusammenführung durchgeführt, und Li Si entwickelte und rebasierte sie später (beachten Sie, dass Li Si zum Hauptzweig wechseln, dann Git Rebase ausführen und dann Git Pull auf die Fernbedienung übertragen muss Ende), dann wird Li Sis neuer Beitrag zum neuen von Zhang San. Die neu eingereichte Basis, Li Sis Beitrag war ursprünglich der neueste, aber der letzte Beitrag zeigte, dass es stattdessen Zhang Sans war, und alles ging schief)

Empfohlenes Lernen: „ Git-Tutorial"

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung der Rebase-Beispiele für Git-Lernen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!