Was machen Git-Rebase und Git-Merge? Was ist der Unterschied?

Wofür werden Git-Rebase und Git-Merge verwendet? Was ist der Unterschied zwischen Git-Rebase und Git-Merge? Der folgende Artikel wird Ihnen den Unterschied zwischen Git-Rebase und Git-Merge vorstellen. Ich hoffe, er wird Ihnen hilfreich sein!

Die Verwendung von Git zur Versionskontrolle sollte einer der Arbeitsabläufe sein, denen die meisten Ingenieure jeden Tag begegnen, aber was ich verwende, ist nichts anderes als push, pull, merge, checkout oder log und andere Befehle. Wenn Sie näher darauf eingehen, können Sie das nicht herausfinden Interview: „Kennst du den Unterschied zwischen Merge und Rebase?“ push、pull、merge、checkout 或 log 等几个指令，更深入一点就一问三不知了，在面试时被问到了这个问题：「你知道 Git 的 merge 和 rebase 有什麽不同吗？」

听完后我直接困惑，对我来说 rebase 就是用来整理 commit 的工具，居然还可以和 merge 做比较？【推荐学习：《Git教程》】

git-rebase

先来说说平常我会用 rebase 这个指令来干嘛，假如我新增了一个单元测试，然后 commit，这时候 log 就会多一条 commit 的纪录：

但是在 commit 完才发现，我少写了另一个测试案例，因此在补上之后，我又 commit 了一次：

这时记录中会多出另外一条 commit，不过对我来说，这两个 commit 在做的其实是同一件事，于是我在 push 到 remote 之前，就会想要先整理一下 commit，把这两条记录合并起来。

要把这两条记录合并起来有两个方法，第一个是 reset 到添加第一个测试案例之前，然后直接做一次 commit。第二个方法就是用 rebase 来处理！

首先让我们看看目前的 log：

我的目的是把 9dc67ff 和 87af945 整理成一个，所以要调整的 commit  是从 init, 也就是  commit id为 7eb57cb 之后的所有 commit，搭配上 rebase 指令的话就是：

git rebase -i 7eb57cb

输入完后就会跳到 vim 的编辑画面：

画面上会看到 7eb57cb 后的所有 commit（目前就只有  9dc67ff 和 87af945 ），接着把 9dc67ff 的 pick 改成 squash，表示把它与前一个 commit 做合并。先点一下 i 后开始用 vim 编辑内容：

编辑完后，可以点 esc 再输入 :wq 做保存，如果只是好奇进来玩看看，不想保存的话就输入 :q!。结束上面的流程后，再查看一次 log，会发现两条 commit 变成一笔了。保存完会跳到 commit message 的画面，这边可以让你输入合并后的 commit message，但我就不改了，一样直接保存：

结束上方的流程后，再查看一次 log，会发现两笔 commit 变成一笔了：

先 nice，上述的操作为 rebase 的 interactive mode，在 git rebase 后输入的 -i 其实就是 interactive 的缩写。

git-merge

大家应该对 merge 指令都非常熟悉，因为在做新功能的时候，通常都会拉一个分支出去，完成后再 merge

Nachdem ich es mir angehört habe, ist Rebase ein Tool zum Organisieren von Commits. [Empfohlenes Lernen: „Git-Tutorial"]

git-rebase

Lassen Sie uns zunächst darüber sprechen, was ich normalerweise mit dem Rebase-Befehl verwende. Wenn ich einen neuen Unit-Test hinzufüge, wird commit und dann log verwendet ein weiterer Datensatz von commit: 🎜🎜🎜Aber ich habe nach dem Commit herausgefunden, dass ich es versäumt habe, einen weiteren Testfall zu schreiben, also habe ich ihn hinzugefügt. Danach habe ich einen Commit durchgeführt Nochmals: 🎜🎜🎜🎜Zu diesem Zeitpunkt wird es ein weiteres commit im Datensatz geben, aber für mich sind diese beiden commit Eigentlich mache ich das Gleiche, also möchte ich, bevor ich auf Remote pushe, die Commits sortieren und die beiden Datensätze zusammenführen. 🎜🎜Es gibt zwei Möglichkeiten, diese beiden Datensätze zusammenzuführen. Die erste besteht darin, vor dem Hinzufügen des ersten Testfalls einen zurückzusetzen und dann direkt einen commit durchzuführen. Die zweite Methode besteht darin, rebase zu verwenden, um damit umzugehen! 🎜🎜Lassen Sie uns zunächst einen Blick auf das aktuelle Protokoll werfen: 🎜🎜🎜🎜Mein Ziel ist es, 9dc67ff und 87af945 in einem zu organisieren Die anzupassenden Commits stammen also von init, d. h. alle Commits nach der Commit-ID lauten 7eb57cb. In Kombination mit dem Befehl rebase ergibt sich Folgendes: 🎜

git checkout string-library

🎜Nach der Eingabe springt es. Gehen Sie zum VIM-Bearbeitungsbildschirm: 🎜🎜🎜🎜Sie sehen alle Commits nach 7eb57cb auf dem Bildschirm (derzeit nur ). 9dc67ff und 87af945) und ändern Sie dann den pick von 9dc67ff in squash, was Zusammenführen bedeutet es mit dem vorherigen Commit. Klicken Sie zuerst auf „i“ und beginnen Sie dann mit der Bearbeitung von Inhalten mit vim: 🎜🎜🎜🎜Nach der Bearbeitung können Sie auf Esc klicken und zum Speichern :wq eingeben. Wenn Sie nur neugierig sind , kommen Sie herein und spielen Sie. Wenn Sie es nicht speichern möchten, geben Sie :q! ein. Nachdem Sie den obigen Vorgang abgeschlossen haben, überprüfen Sie das Protokoll erneut und Sie werden feststellen, dass die beiden Commits zu einem geworden sind. Nach dem Speichern gelangen Sie zum Commit-Nachrichtenbildschirm. Hier können Sie die zusammengeführte Commit-Nachricht eingeben, ich werde sie jedoch nicht ändern und direkt speichern: 🎜🎜🎜🎜Beenden Sie den obigen Vorgang. Endlich , überprüfen Sie das Protokoll erneut und Sie werden feststellen, dass aus zwei Commits eins geworden ist: 🎜🎜🎜🎜Schön zuerst, der obige Vorgang ist der interaktive Modus von Rebase, der nach Git Rebase eingegeben wird - ich bin es tatsächlich die Abkürzung für interaktiv. 🎜

git-merge

🎜Jeder sollte mit dem Merge-Befehl bestens vertraut sein, denn beim Erstellen neuer Features zieht man normalerweise einen Zweig heraus und merge nach Abschluss Kehren Sie zum Hauptzweig zurück, z. B. „master“ oder „develop“. Der Vorgang ist wie folgt: 🎜🎜🎜🎜

在 merge 的时候会有两种情况，第一种是  fast-forward，会把被合并分支的 HEAD 的 reference 移到要合併分支内最新的 commit 上，上方操作的 merge 结果就是 fast-forward，master 的 HEAD 被移到 string-library 的最新 commit，画成图的话就是这样子：

但是如果在执行 merge 的时候产生冲突，那分支的合并行为就会和 fast-forward 有点不同了。举例来说，我分别在 master 和 string-library 的同一个文件添加内容，那当我执行 merge 的时候就会要求先修复冲突：

修复完后，再执行 commit 完成合并，而这一次合并时，会再多一个 commit 是有关 merge 了 string-library 分支的纪录：

这个情况画成图就会像这样子：

git-rebase 与 git-merge 的差异

看完上方对 rebase 和 merge 的介绍后，你也许会想说：

「咦？那这两个不是完全不同的东西吗？」

对的，原本我也是这麽认为，一直到我去看了 git-rebase 的文档，才发现原来我一直误会它了。在 git book 的 rebase 篇章，第一段就说明了，在 Git 里有两种方法可以用来整合两个分支，而这两个在上方都有提到，分别为 merge 和 rebase：

从上方的 merge 例子已经知道了，merge 在合并的时候会有 fast-forward，和冲突时用一个 commit 记录合并变更的两种情形。而 rebase 的整合方式非常有趣，依照关于 rebase 的另一段说明，它可以「把某个分支中所有 commit 的过程，以另一个分支的 commit 为基础重播一遍」：

这是什麽意思呢？首先让我们回到上述的例子，并在 master 分支上用 reset，让 master 的版本回到合并 string-library 之前：

现在我们要用 rebase 指令，将 string-library 所有的 commit 修改，以 master 的 commit 为基础跑一次。使用 rebase 合并的第一步，要先切到想重播 commit 的分支：

git checkout string-library

然后再输入 git rebase 指令，并于后方指定要在哪个分支上重播：

git rebase master

执行结果：

在 rebase 重播 commit 的过程中，和 merge 相似的地方在于，如果有冲突的话还是需要解决，但在解决后，并不是使用 commit 指令进行合并，而是要输入 git rebase --continue，让 rebase 可以继续重播接下来的 commit：

重播完成时，会显示目前重播到哪个 commit，以 string-library 来说就是最新的add string unit test D。这时候的分支关系，画成图就会变成：

上图在经过 rebase 之后，string-library 里 07e38fb 修改，会以 master 的 commit 为基底再重播一次。

需要注意的是，重播后的 commit id 会和原本的不一样，这等于完全改写了分支内所有的 commit 历史纪录。

Außerdem wurde string-library nach der Ausführung des Rebase nicht wirklich wieder mit dem Master-Zweig zusammengeführt, sodass Sie immer noch zurück zum Master-Zweig wechseln müssen, um Merge auszuführen, um die Zusammenführung abzuschließen: string-library 其实还没有被合并回 master 分支上，因此还是要再切回 master 执行 merge，以完成合併：

因为已经先用 rebase 在重播时处理完 commit 的冲突了，所以现在 merge 就会直接走 fast-forward 合并，也不会另外多一个 merge 的 commit 纪录。

使用 git-rebase 合併的优缺点

优点

• 不会在合併时产生多馀的 commit。

• 可以在重播的时候以 commit 为单位处理冲突。

• 合併时会依分支的 commit 排列，能够比较清楚的 review issue 或 feature 处理的过程。如果使用 merge，在合併后就会依照时间顺序穿插排列两个分支的 commit。

• 在贡献开源项目的时候，如果在 push 前先做 rebase，那作者就能够直接以 fast-forward 的方式合并，不需要再另外解冲突。

缺点

最大的缺点就是上方提到的，使用 rebase 会修改 commit 的历史纪录，如果在自己的 local 整理 commit 或是分支那还好，但如果不小心去异动到 remote 的分支，然后又更不小心用了 git push -f，那可能就会被同事讨厌，或被投稿到纯靠北工程师。

该用 git-rebase 或 git-merge？

在查了一些资料后，发现 rebase 和 merge 都各有拥护者，我先阐述他们的想法，再主观提一下自己的观点。

git-merge 派

支持 git-merge 派的工程师们认为，版本纪录有价值的地方就在于项目的 commit，也就是这个项目的「历史实际上发生过哪些事情」，如果你去修改了这些历史纪录那就很不好。因此即使不同分支的内容在 merge 后都混在一起，但这些内容仍然说明了这个项目的历史。

git-rebase 派

支持 git-rebase

Da Rebase verwendet wurde, um die Commit-Konflikte während der Wiedergabe zu behandeln, geht die Zusammenführung jetzt direkt zur Fast-Forward-Merge über, und es wird keinen weiteren Commit-Datensatz für die Zusammenführung geben.

Vor- und Nachteile der Verwendung von git-rebase zum Zusammenführen

Vorteile

• Während des werden keine redundanten Commits generiert zusammenführen.
• Konflikte können während der Wiedergabe in Commit-Einheiten behandelt werden. 🎜
• 🎜Beim Zusammenführen wird es entsprechend dem Commit des Zweigs angeordnet, sodass das Überprüfungsproblem oder der Feature-Verarbeitungsprozess klar verstanden werden kann. Wenn Sie Merge verwenden, werden die Commits der beiden Zweige nach der Zusammenführung in chronologischer Reihenfolge angeordnet. 🎜
• 🎜Wenn Sie zu einem Open-Source-Projekt beitragen und vor dem Pushen eine Rebase durchführen, kann der Autor direkt und im Schnellvorlauf zusammenführen, ohne Konflikte separat lösen zu müssen. 🎜

🎜Nachteile🎜🎜Der größte Nachteil wird oben erwähnt. Wenn Sie Commits oder Branches lokal organisieren, ist das in Ordnung, aber wenn Sie versehentlich Änderungen vornehmen Wenn Sie den Remote-Zweig verlassen und dann versehentlich git push -f verwenden, werden Sie möglicherweise von Ihren Kollegen gehasst oder einem rein nordischen Ingenieur unterworfen. 🎜🎜🎜Soll ich Git-Rebase oder Git-Merge verwenden? 🎜🎜🎜Nachdem ich einige Informationen überprüft hatte, stellte ich fest, dass sowohl Rebase als auch Merge ihre eigenen Unterstützer haben. Ich werde zuerst ihre Ideen erläutern und dann subjektiv meine eigene Meinung erwähnen. 🎜🎜🎜git-merge Pai🎜🎜🎜 unterstützt git-merge Die Ingenieure von Pai glauben, dass der Wert von Versionsdatensätzen in den Commits des Projekts liegt, d. h. in der „Geschichte dieses Projekts, die tatsächlich stattgefunden hat“. „Was für Dinge“, es wäre sehr schlecht, wenn Sie diese historischen Aufzeichnungen ändern würden. Auch wenn die Inhalte verschiedener Zweige nach der Zusammenführung vermischt werden, veranschaulichen sie dennoch die Geschichte des Projekts. 🎜🎜🎜Git-Rebase-Fraktion 🎜🎜🎜 unterstützt git-rebase. Bei Commit geht es um den „Evolutionsprozess“ dieses Projekts Es wurde geändert. Der Commit-Verlauf wurde entfernt, aber was passiert ist, hat sich nicht geändert. Da wir künftigen Generationen eine klarere und prägnantere Aufzeichnung zur Verfügung stellen können, sollten wir dies tun. 🎜🎜🎜Persönliche subjektive Meinung🎜🎜🎜Ich persönlich werde Git-Rebase weiterhin verwenden, um Commits zu ändern, um die historischen Datensätze einfacher und leichter lesbar zu machen, aber die Verwendung ist auf die Übertragung auf Remote beschränkt Heute, egal wie chaotisch es ist, ich werde sie schließlich nicht ändern. Wenn ich sie nicht nach Belieben ändere, respektiere ich andere Mitglieder des Teams. 🎜🎜【Empfohlene verwandte Video-Tutorials: 🎜Web-Frontend🎜】🎜

Das obige ist der detaillierte Inhalt vonWas machen Git-Rebase und Git-Merge? Was ist der Unterschied?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!