Was ist Merge in Git?

In Git bedeutet „Merge“ „Zusammenführen“. Der Befehl „Merge“ kann in Git-Pull auch zum Integrieren eines anderen Code-Repositorys verwendet werden Verschmelzung von einem Zweig zum anderen.

Die Betriebsumgebung dieses Tutorials: Windows 7-System, Git-Version 2.30.0, Dell G3-Computer.

Vollständige Analyse von Git-Merge

Git-Merge ist ein in Git häufig verwendeter Befehl. Wenn Sie nicht aufpassen, werden Sie auf das Problem stoßen, Code zu verlieren. Daher werde ich von Git entmutigt. Dieser Artikel bietet eine vollständige und detaillierte Einführung in den Befehl git-merge basierend auf Git 2.8.2, insbesondere in Bezug auf das durch Cross-Merging verursachte Codeverlustproblem. Ich gebe am Ende des Artikels meine eigenen Vorschläge und hoffe, Git-Benutzern zu helfen . Der in diesem Artikel vorgestellte Inhalt basiert auf Git 2.8.2

Der Befehl git-merge ist eine Operation, die zum Zusammenführen von zwei oder mehr Entwicklungsverläufen verwendet wird. Er kann normalerweise auch als „git merge“ geschrieben werden.

1.git-merge-bezogene Optionsparameter

1.1 Zusammenfassung

Im Befehl git-merge gibt es die folgenden drei Parameter:

• git merge [-n] [--stat] [- - no-commit] [--squash] [--[no-]edit] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [-- [ no-]rerere-autoupdate] [-m <msg>] [<commit>...]</commit></msg></keyid></strategy-option></strategy>
git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]</commit></msg></keyid></strategy-option></strategy>
• git merge <msg> HEAD <commit>...</commit></msg>
• git merge --abort

1.2git-merge简介

git-merge命令是用于从指定的commit(s)合并到当前分支的操作。

注：这里的指定commit(s)是指从这些历史commit节点开始，一直到当前分开的时候。

git-merge命令有以下两种用途：

1. 用于git-pull中，来整合另一代码仓库中的变化（即：git pull = git fetch + git merge）
2. 用于从一个分支到另一个分支的合并

假设下面的历史节点存在，并且当前所在的分支为“master”：

那么git merge topic命令将会把在master分支上二者共同的节点（E节点）之后分离的节点（即topic分支的A B C节点）重现在master分支上，直到topic分支当前的commit节点（C节点），并位于master分支的顶部。并且沿着master分支和topic分支创建一个记录合并结果的新节点，该节点带有用户描述合并变化的信息。

即下图中的H节点，C节点和G节点都是H节点的父节点。

1.3git merge <msg> HEAD <commit>...</commit></msg>命令

该命令的存在是由于历史原因，在新版本中不应该使用它，应该使用git merge -m <msg> <commit>....</commit></msg>进行替代

1.4git merge --abort命令

该命令仅仅在合并后导致冲突时才使用。git merge --abort将会抛弃合并过程并且尝试重建合并前的状态。但是，当合并开始时如果存在未commit的文件，git merge --abort在某些情况下将无法重现合并前的状态。（特别是这些未commit的文件在合并的过程中将会被修改时）

警告：运行git-merge时含有大量的未commit文件很容易让你陷入困境，这将使你在冲突中难以回退。因此非常不鼓励在使用git-merge时存在未commit的文件，建议使用git-stash命令将这些未commit文件暂存起来，并在解决冲突以后使用git stash pop把这些未commit文件还原出来。

2.参数

本部分用于介绍git-merge命令中使用的参数

2.1--commit和--no-commit

--commit参数使得合并后产生一个合并结果的commit节点。该参数可以覆盖--no-commit。
--no-commit参数使得合并后，为了防止合并失败并不自动提交，能够给使用者一个机会在提交前审视和修改合并结果。

2.2--edit和-e以及--no-edit

--edit和-e用于在成功合并、提交前调用编辑器来进一步编辑自动生成的合并信息。因此使用者能够进一步解释和判断合并的结果。
--no-editgit merge <msg>.. . </msg>

git merge --abort🎜1.2 Einführung in git-merge🎜🎜Der Befehl git-merge wird verwendet, um das angegebene Commit zu entfernen ( s) Der Vorgang des Zusammenführens in den aktuellen Zweig. 🎜🎜🎜Hinweis: Die hier angegebenen Commits beziehen sich auf den Beginn von diesen historischen Commit-Knoten bis zur aktuellen Trennung. 🎜🎜🎜Der Befehl git-merge hat die folgenden zwei Verwendungszwecke: 🎜

🎜 wird in git-pull verwendet, um Änderungen in ein anderes Code-Repository zu integrieren (z. B. git pull = git fetch + git merge) 🎜Wird verwendet zum Zusammenführen von einem Zweig zum anderen

🎜Angenommen, der folgende historische Knoten existiert und der aktuelle Zweig ist „Master“:
🎜

🎜🎜 Dann der git Der Befehl merge topic reproduziert die Knoten, die nach dem gemeinsamen Knoten (E-Knoten) im Master-Zweig getrennt wurden (d. h. die A B C-Knoten des Topic-Zweigs) im Master-Zweig, bis der Commit-Knoten (C Knoten) befindet sich oben im Hauptzweig. Und erstellen Sie einen neuen Knoten entlang des Hauptzweigs und des Themenzweigs, um die Zusammenführungsergebnisse aufzuzeichnen. Dieser Knoten enthält die Informationen des Benutzers, die die Zusammenführungsänderungen beschreiben. 🎜🎜🎜Das heißt, der H-Knoten in der Abbildung unten, der C-Knoten und der G-Knoten sind beide die übergeordneten Knoten des H-Knotens. 🎜🎜

🎜🎜1.3git merge <msg> HEAD <commit>...</commit></msg> Befehl🎜🎜Dieser Befehl existiert aus historischen Gründen und sollte in neuen Versionen nicht verwendet werden ersetzt werden durch git merge -m <msg> <commit>....</commit></msg>🎜🎜1.4git merge --abort command🎜🎜Dieser Befehl dient nur der Verwendung wenn es nach der Zusammenführung zu Konflikten kommt. git merge --abort bricht den Zusammenführungsprozess ab und versucht, den Zustand vor dem Zusammenführen wiederherzustellen. Wenn jedoch zu Beginn der Zusammenführung nicht festgeschriebene Dateien vorhanden sind, kann git merge --abort in einigen Fällen den Status vor der Zusammenführung nicht reproduzieren. (Vor allem, wenn diese nicht festgeschriebenen Dateien während des Zusammenführungsprozesses geändert werden) 🎜🎜🎜Warnung: Es kann leicht zu Problemen kommen, wenn git-merge mit einer großen Anzahl nicht festgeschriebener Dateien ausgeführt wird Es fällt Ihnen schwer, sich aus einem Konflikt zurückzuziehen. Daher wird dringend davon abgeraten, nicht festgeschriebene Dateien zu verwenden, wenn Sie git-merge verwenden. Es wird empfohlen, den Befehl git-stash zu verwenden, um diese nicht festgeschriebenen Dateien vorübergehend zu speichern und die Konflikte zu lösen . Verwenden Sie git stash pop, um diese nicht festgeschriebenen Dateien wiederherzustellen. 🎜🎜🎜2. Parameter🎜🎜In diesem Abschnitt werden die im Befehl git-merge verwendeten Parameter vorgestellt🎜🎜2.1--commit und --no -commit 🎜🎜--commitDer Parameter bewirkt, dass nach dem Zusammenführen ein Commit-Knoten des zusammengeführten Ergebnisses generiert wird. Dieser Parameter kann --no-commit überschreiben. Der Parameter
--no-commit bewirkt, dass die Zusammenführung nicht automatisch übermittelt wird, um zu verhindern, dass die Zusammenführung fehlschlägt, und gibt dem Benutzer die Möglichkeit, die Zusammenführungsergebnisse vor der Übermittlung zu überprüfen und zu ändern. 🎜🎜2.2 --edit und -e und --no-edit🎜🎜--edit und -e wird verwendet, um den Editor aufzurufen, um die automatisch generierten Zusammenführungsinformationen vor der erfolgreichen Zusammenführung und Übermittlung weiter zu bearbeiten. Daher können Benutzer die Ergebnisse der Fusion weiter interpretieren und beurteilen. Der Parameter
--no-edit kann verwendet werden, um automatisch zusammengeführte Informationen zu akzeptieren (davon wird im Allgemeinen abgeraten). 🎜

Wenn Sie beim Zusammenführen den Parameter -m angegeben haben (unten beschrieben), ist die Verwendung von --edit (oder -e) immer noch nützlich , dadurch wird der in -m enthaltene Inhalt im Editor weiter bearbeitet. -m参数（下文介绍），使用 --edit（或-e）依然是有用的，这将在编辑器中进一步编辑-m所含的内容。

旧版本的节点可能并不允许用户去编辑合并日志信息。

2.3--ff命令

--ff是指fast-forward命令。当使用fast-forward模式进行合并时，将不会创造一个新的commit节点。默认情况下，git-merge采用fast-forward模式。
关于fast-forward模式的详细解释，请看我的另一篇文章：一个成功的Git分支模型的“关于fast forward”一节。

2.4--no-ff命令

即使可以使用fast-forward模式，也要创建一个新的合并节点。这是当git merge在合并一个tag时的默认行为。

2.5--ff-only命令

除非当前HEAD节点已经up-to-date（更新指向到最新节点）或者能够使用fast-forward模式进行合并，否则的话将拒绝合并，并返回一个失败状态。

2.5 --log[=<n>]</n>和 --no-log

--log[=<n>]</n>将在合并提交时，除了含有分支名以外，还将含有最多n个被合并commit节点的日志信息。
--no-log并不会列出该信息。

2.6 --stat, -n, --no-stat命令

--stat参数将会在合并结果的末端显示文件差异的状态。文件差异的状态也可以在git配置文件中的merge.stat配置。
相反，-n, --no-stat参数将不会显示该信息。

2.7--squash 和--no-squash

--squash 当一个合并发生时，从当前分支和对方分支的共同祖先节点之后的对方分支节点，一直到对方分支的顶部节点将会压缩在一起，使用者可以经过审视后进行提交，产生一个新的节点。

注意1:该参数和--no-ff冲突

注意2:该参数使用后的结果类似于在当前分支提交一个新节点。在某些情况下这个参数非常有用，例如使用Git Flow时（关于Git Flow，请参考：一个成功的Git分支模型），功能分支在进行一个功能需求的研发时，开发者可能在本地提交了大量且无意义的节点，当需要合并到develop分支时，可能仅仅需要用一个新的节点来表示这一长串节点的修改内容，这时--squash命令将会发挥作用。此外，如果功能分支的多次提交并不是琐碎而都是有意义的，使用--no-ff命令更为合适。
--no-squash的作用正好相反。

2.8 -s <strategy></strategy>和 --strategy=<strategy></strategy>

-s <strategy></strategy>和 --strategy=<strategy></strategy>用于指定合并的策略。默认情况如果没有指定该参数，git将按照下列情况采用默认的合并策略：

1. 合并节点只含有单个父节点时（如采用fast-forward模式时），采用recursive策略（下文介绍）。
2. 合并节点含有多个父节点时(如采用no-fast-forward模式时)，采用octopus策略（下文介绍）。

2.9 -X <option></option>和 --strategy-option=<option></option>

在-s <strategy></strategy>时指定该策略的具体参数（下文介绍）。

2.10 --verify-signatures, --no-verify-signatures

Ältere Versionen von Knoten erlauben es Benutzern möglicherweise nicht, Zusammenführungsprotokollinformationen zu bearbeiten.

2.3--ff-Befehl 🎜--ff bezieht sich auf den Schnellvorlaufbefehl. Beim Zusammenführen im Schnellvorlaufmodus wird kein neuer Commit-Knoten erstellt. Standardmäßig verwendet git-merge den Schnellvorlaufmodus. 🎜Eine ausführliche Erklärung des Schnellvorlaufmodus finden Sie im Abschnitt „Über den Schnellvorlauf“ meines anderen Artikels: Ein erfolgreiches Git-Branching-Modell. 🎜

2.4--no-ff-Befehl🎜🎜Erstellen Sie einen neuen Zusammenführungsknoten, auch wenn der Schnellvorlaufmodus verwendet werden kann. Dies ist das Standardverhalten, wenn git merge ein Tag zusammenführt. 🎜

2.5--ff-only-Befehl🎜🎜Es sei denn, der aktuelle HEAD-Knoten ist auf dem neuesten Stand (aktualisiert, um auf den neuesten Knoten zu verweisen) oder kann im Schnellvorlaufmodus zusammengeführt werden Andernfalls wird die Zusammenführung abgelehnt und ein Fehlerstatus zurückgegeben. 🎜

2.5 --log[=<n>]</n> und --no-log🎜🎜--log[=<n>] </n>Beim Zusammenführen und Senden enthält es zusätzlich zum Zweignamen auch die Protokollinformationen von bis zu n zusammengeführten Festschreibungsknoten. 🎜--no-log listet diese Informationen nicht auf. 🎜

2.6 --stat, -n, --no-stat Befehle 🎜🎜--statDer Parameter zeigt den Status der Dateiunterschiede am Ende des zusammengeführten Ergebnisses an. Der Status von Dateiunterschieden kann auch in merge.stat in der Git-Konfigurationsdatei konfiguriert werden. 🎜Im Gegenteil, die Parameter -n, --no-stat zeigen diese Informationen nicht an. 🎜

2.7--squash und --no-squash🎜🎜--squash Wenn eine Zusammenführung erfolgt, vom aktuellen Zweig und Der andere Zweigknoten nach dem gemeinsamen Vorfahrenknoten des anderen Zweigs wird zusammengedrückt. Der Benutzer kann ihn nach der Überprüfung einreichen, um einen neuen Knoten zu generieren. 🎜🎜🎜Hinweis 1: Dieser Parameter steht in Konflikt mit --no-ff🎜🎜🎜Hinweis 2: Das Ergebnis der Verwendung dieses Parameters ähnelt dem Senden eines neuen Knotens im aktuellen Zweig. Dieser Parameter ist in einigen Fällen sehr nützlich, beispielsweise bei der Verwendung von Git Flow (Informationen zu Git Flow finden Sie unter: Ein erfolgreiches Git-Zweigmodell. Wenn der Funktionszweig eine funktionale Anforderung entwickelt, kann der Entwickler eine große Anzahl lokal einreichen). Wenn bedeutungslose Knoten in den Entwicklungszweig eingefügt werden müssen, müssen Sie möglicherweise nur einen neuen Knoten verwenden, um den Änderungsinhalt dieser langen Knotenliste darzustellen. code> Befehl kommt ins Spiel. Wenn außerdem die mehrfachen Übermittlungen des Feature-Zweigs nicht trivial, aber sinnvoll sind, ist die Verwendung des Befehls --no-ff besser geeignet. 🎜--no-squash macht genau das Gegenteil. 🎜

2.8 -s <strategy></strategy> und --strategy=<strategy></strategy>🎜🎜-s und --strategy=<strategy></strategy> werden verwendet, um die Zusammenführungsstrategie anzugeben. Wenn dieser Parameter nicht angegeben ist, verwendet Git standardmäßig die Standard-Merge-Strategie gemäß den folgenden Bedingungen: 🎜

1. Wenn der Merge-Knoten nur einen einzelnen übergeordneten Knoten enthält (z. B. bei Verwendung des Schnellvorlaufmodus) , die rekursive Strategie (unten beschrieben).
2. Wenn der zusammengeführte Knoten mehrere übergeordnete Knoten enthält (z. B. wenn der No-Fast-Forward-Modus verwendet wird), wird die Octopus-Strategie (unten beschrieben) verwendet.

2.9 -X <option></option> und --strategy-option=<option></option>🎜🎜 in - s <strategy></strategy> bei der Angabe der spezifischen Parameter der Strategie (unten beschrieben). 🎜

2.10 --verify-signatures, --no-verify-signatures🎜🎜 Wird verwendet, um zu überprüfen, ob der zusammengeführte Knoten eine GPG-Signatur hat, und um diese zusammenzuführen. Knoten ignorieren die keine GPG-Signaturüberprüfung haben. 🎜(Das folgende Zitat stammt aus einem nachgedruckten Artikel. Da ich den ursprünglichen Autor nicht gefunden habe, kann ich die Informationen zum ursprünglichen Autor und den Link zum ursprünglichen Artikel nicht angeben. Wenn es einen Verstoß gibt, teilen Sie mir dies bitte per privater Nachricht oder Kommentar mit Das folgende Zitat werde ich löschen.)🎜

GPG ist eine Verschlüsselungssoftware. Sie können den von GPG generierten öffentlichen Schlüssel verwenden, um Ihre Dateien und Codes sicher im Internet zu verbreiten.
Warum sagt man sicher? Nehmen Sie als Beispiel das von Google entwickelte Repo. Jedes Meilenstein-Tag verfügt über eine GPG-Verschlüsselungsüberprüfung. Wenn Sie Änderungen an Meilenstein v1.12.3 vornehmen möchten, ist dies auf jeden Fall möglich Erstellen Sie ein Tag mit demselben Namen, um auf Ihren Änderungspunkt zu verweisen. Wenn Sie Ihr geändertes Projekt jedoch erneut klonen, werden Sie feststellen, dass Ihre Änderungen an diesem Meilenstein-Tag nicht erkannt werden und die Überprüfung fehlschlägt, was dazu führt, dass Ihre Änderungen hier nicht normal implementiert werden. Dies ist die Aufgabe der GPG-Verifizierung, die sicherstellt, dass die vom Projektautor (Inhaber des privaten Schlüssels) festgelegten Meilensteine ​​nicht von anderen geändert werden können. Dann kann man sagen, dass der Code des Autors sicher verbreitet wird.
Warum besteht so ein Bedarf? Von der Entwicklung über die Veröffentlichung bis hin zu späteren Update-Iterationen eines Projekts wird es auf jeden Fall eine Reihe stabiler Versionen und Entwicklungsversionen geben (es gibt Instabilitätsfaktoren). Als Projektinitiatoren und -inhaber haben sie das Recht, eine stabile Version zu definieren, die sie anerkennen. Diese stabile Version erlaubt anderen Entwicklern keine Änderungen. Nehmen Sie als Beispiel das Repo-Projekt von Google. Der Projektinhaber definiert Punkt A im Projektentwicklungsprozess als die stabile Version v1.12.3. Nachdem Benutzer die Version v1.12.3 heruntergeladen haben, werden sie definitiv die von Punkt A generierten Projekte und Produkte verwenden. Auch wenn andere Entwickler v1.12.3 lokal neu spezifizieren und an ihrem modifizierten Punkt B angeben können, besteht das Problem, dass die GPG-Signaturüberprüfung fehlschlägt, wenn die modifizierte Version schließlich von Benutzern verwendet wird. Das heißt, dies ist der Fall Die Änderung wird nicht wirksam.

2.11 -summary, --no-summary—summary,--no-summary

和--stat与 --no-stat相似，并将在未来版本移除。

2.12 -q和 --quiet

静默操作，不显示合并进度信息。

2.13 -v和 --verbose

显示详细的合并结果信息。

2.14 --progress和 --no-progress

切换是否显示合并的进度信息。如果二者都没有指定，那么在标准错误发生时，将在连接的终端显示信息。请注意，并不是所有的合并策略都支持进度报告。

2.15-S[<keyid>]</keyid>和 --gpg-sign[=<keyid>]</keyid>

GPG签名。

2.16-m <msg></msg>

设置用于创建合并节点时的提交信息。
如果指定了--log参数，那么commit节点的短日志将会附加在提交信息里。

2.17--[no-]rerere-autoupdate

rerere即reuse recorded resolution，重复使用已经记录的解决方案。它允许你让 Git 记住解决一个块冲突的方法，这样在下一次看到相同冲突时，Git 可以为你自动地解决它。

2.18--abort

und --stat und --no-stat code code> ist ähnlich und wird in einer zukünftigen Version entfernt. <p></p>2.12 <code>-q und --quiet

Betrieb geräuschlos, es werden keine Informationen zum Zusammenführungsfortschritt angezeigt.

2.13 -v und --verbose

Detaillierte Informationen zum Zusammenführungsergebnis anzeigen.

2.14 --progress und --no-progress

Wählen Sie, ob zusammengeführte Fortschrittsinformationen angezeigt werden sollen. Wenn keines von beiden angegeben ist, wird auf dem angeschlossenen Terminal eine Meldung angezeigt, wenn ein Standardfehler auftritt. Beachten Sie, dass nicht alle Zusammenführungsstrategien Fortschrittsberichte unterstützen.

2.15-S[<keyid>]</keyid> und --gpg-sign[=<keyid>]</keyid>

GPG-Signatur.

2.16-m <msg></msg>

🎜Legen Sie die Commit-Informationen fest, die beim Erstellen von Zusammenführungsknoten verwendet werden. 🎜Wenn der Parameter --log angegeben ist, wird das Kurzprotokoll des Commit-Knotens an die Commit-Nachricht angehängt. 🎜🎜2.17--[no-]rerere-autoupdate🎜🎜rerere bedeutet, die aufgezeichnete Auflösung wiederzuverwenden und die aufgezeichnete Lösung wiederzuverwenden. Damit können Sie Git bitten, sich zu merken, wie ein Blockkonflikt gelöst werden soll, sodass Git ihn beim nächsten Mal, wenn Sie denselben Konflikt sehen, automatisch für Sie lösen kann. 🎜🎜2.18--abort🎜🎜Beenden Sie den aktuellen Prozess zur Bearbeitung von Zusammenführungskonflikten und versuchen Sie, den Zustand vor der Zusammenführung wiederherzustellen. 🎜🎜3. Weitere Konzepte zum Zusammenführen🎜🎜3.1 Erkennung vor dem Zusammenführen🎜🎜Beim Zusammenführen externer Zweige sollten Sie Ihre eigenen Zweige sauber halten, da es sonst bei Zusammenführungskonflikten zu großen Problemen kommt. 🎜Um zu vermeiden, dass beim Zusammenführen von Commits irrelevante Dateien aufgezeichnet werden, werden die Befehle git-pull und git-merge angehalten, wenn im HEAD-Knoten, auf den der Index verweist, nicht festgeschriebene Dateien registriert sind. 🎜🎜3.2Fast-Forward-Merge🎜🎜Normalerweise führt das Zusammenführen von Zweigen zu einem Merge-Knoten, in einigen Sonderfällen gibt es jedoch Ausnahmen. Wenn Sie beispielsweise den Befehl git pull aufrufen, um den Remote-Code zu aktualisieren, und der lokale Zweig keine Commits hat, ist es nicht erforderlich, einen Zusammenführungsknoten zu generieren. In diesem Fall wird kein Merge-Knoten generiert und HEAD zeigt direkt auf den aktualisierten Top-Code. Diese Merge-Strategie ist eine Fast-Forward-Merge. 3.3 Details zur Zusammenführung Knoten des anderen Zweigs zusammen als übergeordneter Knoten. 🎜Eine zusammengeführte Version sorgt dafür, dass die Änderungen in allen zugehörigen Zweigen konsistent sind, einschließlich des Commit-Knotens, des HEAD-Knotens und des Indexzeigers, und der Knotenbaum wird aktualisiert. Solange sich die Dateien in diesen Knoten nicht überschneiden, werden Änderungen an diesen Dateien im Knotenbaum geändert und aktualisiert. 🎜Wenn diese Änderungen nicht explizit zusammengeführt werden können, passiert Folgendes: 🎜

1. Der Knoten, auf den der HEAD-Zeiger zeigt, bleibt unverändert
2. Der MERGE_HEAD-Zeiger wird über anderen Zweigen platziertMERGE_HEAD指针被置于其他分支的顶部
3. 已经合并干净的路径在index文件和节点树中同时更新
4. 对于冲突路径，index文件记录了三个版本：版本1记录了二者共同的祖先节点，版本2记录了当前分支的顶部，即HEAD，版本3记录了MERGE_HEAD。节点树中的文件包含了合并程序运行后的结果。例如三路合并算法会产生冲突。
5. 其他方面没有任何变化。特别地，你之前进行的本地修改将继续保持原样。
   如果你尝试了一个导致非常复杂冲突的合并，并想重新开始，那么可以使用git merge --abort

关于三路合并算法：
三路合并算法是用于解决冲突的一种方式，当产生冲突时，三路合并算法会获取三个节点：本地冲突的B节点，对方分支的C节点，B，C节点的共同最近祖先节点A。三路合并算法会根据这三个节点进行合并。具体过程是，B，C节点和A节点进行比较，如果B，C节点的某个文件和A节点中的相同，那么不产生冲突；如果B或C只有一个和A节点相比发生变化，那么该文件将会采用该变化了的版本；如果B和C和A相比都发生了变化，且变化不相同，那么则需要手动去合并;如果B，C都发生了变化，且变化相同，那么并不产生冲突，会自动采用该变化的版本。最终合并后会产生D节点，D节点有两个父节点，分别为B和C。

3.4合并tag

当合并一个tag时，Git总是创建一个合并的提交，即使这时能够使用fast-forward模式。该提交信息的模板预设为该tag的信息。额外地，如果该tag被签名，那么签名的检测信息将会附加在提交信息模板中。

3.5冲突是如何表示的

当产生合并冲突时，该部分会以, <code>=======和 表示。在=======之前的部分是当前分支这边的情况，在=======之后的部分是对方分支的情况。

3.6如何解决冲突

在看到冲突以后，你可以选择以下两种方式：

• 决定不合并。这时，唯一要做的就是重置index到HEAD节点。git merge --abort用于这种情况。
• 解决冲突。Git会标记冲突的地方，解决完冲突的地方后使用git add加入到index中，然后使用git commit产生合并节点。
  你可以用以下工具来解决冲突:
• 使用合并工具。git mergetool将会调用一个可视化的合并工具来处理冲突合并。
• 查看差异。git diff将会显示三路差异（三路合并中所采用的三路比较算法）。
• 查看每个分支的差异。git log --merge -p <path></path>将会显示HEAD版本和MERGE_HEAD版本的差异。
• 查看合并前的版本。git show :1:文件名显示共同祖先的版本，git show :2:文件名显示当前分支的HEAD版本，git show :3:文件名显示对方分支的MERGE_HEAD版本。

4.合并策略

Git可以通过添加-s参数来指定合并的策略。一些合并策略甚至含有自己的参数选项，通过-X<option></option>

Der zusammengeführte saubere Pfad wird gleichzeitig in der Indexdatei und im Knotenbaum aktualisiert

Für widersprüchliche Pfade zeichnet die Indexdatei drei Versionen auf: Version 1 zeichnet den gemeinsamen Vorfahrenknoten beider auf, Version 2 zeichnet den Anfang des aktuellen Zweigs auf, also HEAD, und Version 3 zeichnet MERGE_HEAD auf. Die Dateien im Knotenbaum enthalten die Ergebnisse der Ausführung des Zusammenführungsprogramms. Beispielsweise kann der Drei-Wege-Merge-Algorithmus zu Konflikten führen.

Keine weiteren Änderungen. Insbesondere bleiben lokale Änderungen, die Sie zuvor vorgenommen haben, erhalten.

Wenn Sie eine Zusammenführung versucht haben, die zu einem sehr komplexen Konflikt geführt hat, und von vorne beginnen möchten, können Sie git merge --abort verwenden. 🎜

🎜Über den Drei-Wege-Zusammenführungsalgorithmus : 🎜Drei Der Pfadzusammenführungsalgorithmus ist eine Möglichkeit, Konflikte zu lösen. Wenn ein Konflikt auftritt, erhält der Drei-Wege-Zusammenführungsalgorithmus drei Knoten: den B-Knoten des lokalen Konflikts, den C-Knoten des anderen Zweigs und den gemeinsamen nächsten Vorfahrenknoten A der B- und C-Knoten. Der Drei-Wege-Zusammenführungsalgorithmus führt die Zusammenführung basierend auf diesen drei Knoten durch. Der spezifische Prozess besteht darin, die Knoten B und C mit Knoten A zu vergleichen. Wenn eine Datei in Knoten B und C mit der in Knoten A übereinstimmt, liegt kein Konflikt vor, wenn sich nur eine von B oder C im Vergleich zu Knoten geändert hat A, dann übernimmt die Datei die geänderte Version; wenn sich B und C im Vergleich zu A geändert haben und die Änderungen nicht identisch sind, müssen Sie sie manuell zusammenführen, wenn sich B und C geändert haben und die Änderungen gleich sind , dann entsteht kein Konflikt und die geänderte Version wird automatisch übernommen. Nach der endgültigen Fusion wird ein D-Knoten generiert. Der D-Knoten hat zwei übergeordnete Knoten, nämlich B und C. 🎜

🎜3.4 Tags zusammenführen🎜🎜Beim Zusammenführen eines Tags erstellt Git immer einen zusammengeführten Commit, auch wenn der Schnellvorlaufmodus verwendet werden kann. Die Vorlage der Übermittlungsinformationen ist auf die Informationen des Tags voreingestellt. Wenn das Tag signiert ist, werden außerdem Informationen zur Signaturerkennung an die Commit-Nachrichtenvorlage angehängt. 🎜🎜3.5 Wie Konflikte ausgedrückt werden🎜🎜Wenn ein Zusammenführungskonflikt auftritt, wird dieser Teil mit , <code>==== markiert == == und . Der Teil vor ======= ist die Situation auf dem aktuellen Zweig und der Teil nach ======= ist die Situation auf der anderen Seite Zweig. 🎜🎜3.6 So lösen Sie Konflikte🎜🎜Nachdem Sie den Konflikt gesehen haben, können Sie die folgenden zwei Methoden wählen: 🎜

🎜Entscheiden Sie sich, nicht zusammenzuführen. Zu diesem Zeitpunkt müssen Sie lediglich den Index auf den HEAD-Knoten zurücksetzen. In diesem Fall wird git merge --abort verwendet. 🎜🎜Konflikte lösen. Git markiert den Konflikt, indem Sie ihn mit git add zum Index hinzufügen und dann mit git commit einen Merge-Knoten generieren. 🎜Sie können die folgenden Tools verwenden, um Konflikte zu lösen: 🎜🎜Verwenden Sie das Zusammenführungstool. git mergetool ruft ein visuelles Zusammenführungstool auf, um widersprüchliche Zusammenführungen zu behandeln. 🎜🎜Sehen Sie den Unterschied. git diff zeigt Drei-Wege-Unterschiede an (der Drei-Wege-Vergleichsalgorithmus, der bei Drei-Wege-Zusammenführungen verwendet wird). 🎜🎜Sehen Sie sich die Unterschiede für jede Filiale an. git log --merge -p <path></path> zeigt den Unterschied zwischen der HEAD-Version und der MERGE_HEAD-Version an. 🎜🎜Sehen Sie sich die Pre-Merge-Version an. git show :1:File name zeigt die gemeinsame Vorgängerversion an, git show :2:File name zeigt die HEAD-Version des aktuellen Zweigs an, git show :3 :Dateiname zeigt die MERGE_HEAD-Version des Zweigs der anderen Partei an. 🎜

4. Zusammenführungsstrategie

🎜Git kann die Zusammenführungsstrategie angeben, indem es den Parameter -s hinzufügt. Einige Merge-Strategien verfügen sogar über eigene Parameteroptionen, die über -X<option></option> festgelegt werden können. (Vergessen Sie nicht, dass das Zusammenführen sowohl in den Befehlen „git merge“ als auch „git pull“ erfolgen kann, daher gilt diese Zusammenführungsstrategie auch für „git pull“.) 🎜🎜4.1resolve🎜🎜 verwendet nur den Drei-Wege-Zusammenführungsalgorithmus, um die oberen Knoten zweier Zweige zusammenzuführen (z. B. den aktuellen Zweig und einen anderen Zweig, den Sie heruntergezogen haben). Diese Zusammenführungsstrategie folgt einem Drei-Wege-Zusammenführungsalgorithmus, bei dem die HEAD-Knoten der beiden Zweige und die gemeinsamen untergeordneten Knoten eine Drei-Wege-Zusammenführung durchführen. 🎜Was uns natürlich wirklich stört, ist der Fall der Cross-Cross-Merge. Die sogenannte Kreuzverschmelzung bezieht sich auf die Situation, in der es mehrere gemeinsame Vorfahrenknoten gibt. Wenn beispielsweise zwei Zweige zusammengeführt werden, ist es sehr wahrscheinlich, dass zu diesem Zeitpunkt zwei gemeinsame Vorfahrenknoten vorhanden sind zum Drei-Wege-Merge-Algorithmus (da gemeinsame Vorfahrenknoten nicht eindeutig sind). So geht die Lösungsstrategie mit Cross-Merge-Problemen um. Weitere Informationen finden Sie unter „Versionskontrolle mit Git“ hier: 🎜

In kreuz und quer verlaufenden Zusammenführungssituationen, in denen es mehr als eine mögliche Zusammenführungsbasis gibt, funktioniert die Lösungsstrategie folgendermaßen: Wählen Sie eine der möglichen Zusammenführungsbasen aus und hoffen Sie auf das Beste. Das ist eigentlich nicht so schlimm, wie es sich anhört. Es stellt sich häufig heraus, dass die Benutzer an verschiedenen Teilen des Codes gearbeitet haben. In diesem Fall erkennt Git, dass einige bereits vorhandene Änderungen erneut zusammengeführt werden, und überspringt die doppelten Änderungen, um den Konflikt zu vermeiden die durchaus zu Konflikten führen, zumindest sollte der Konflikt für den Entwickler leicht zu handhaben sein

Hier eine kurze Übersetzung: Bei Cross-Merging gibt es mehr als einen Merge-Referenzpunkt (gemeinsamer Vorfahrenknoten) und der Die Lösungsstrategie funktioniert folgendermaßen: Wählen Sie einen der möglichen Basispunkte für die Zusammenführung aus und hoffen Sie, dass dies das beste Ergebnis der Zusammenführung ist. Das ist eigentlich gar nicht so schlimm, wie es sich anhört. Normalerweise ändern Benutzer verschiedene Teile des Codes. In diesem Fall sind viele Zusammenführungskonflikte tatsächlich redundant und wiederholen sich. Wenn Sie zum Zusammenführen die Auflösung verwenden, sind die erzeugten Konflikte einfacher zu handhaben und es gibt nur sehr wenige Fälle, in denen Code tatsächlich verloren geht.

4.2rekursiv

verwendet nur den Drei-Wege-Zusammenführungsalgorithmus, um zwei Zweige zusammenzuführen. Anders als bei der Auflösung wird diese Zusammenführungsmethode rekursiv aufgerufen, ausgehend von den verschiedenen Knoten der beiden Zweige nach dem gemeinsamen Vorfahrenknoten. Wenn ein Konflikt auftritt, wird der Drei-Wege-Zusammenführungsalgorithmus rekursiv aufgerufen. dann die Datei Die Zusammenführung wird nicht mehr fortgesetzt und Konflikte werden direkt ausgelöst. Andere Dateien ohne Konflikte werden bis zum obersten Knoten ausgeführt. Darüber hinaus ist dieser Ansatz in der Lage, Vorgänge zu erkennen und zu verarbeiten, bei denen Dateinamen geändert werden. Dies ist die Standard-Merge-Aktion zum Zusammenführen und Abrufen von Git-Code.
Die rekursive Zusammenführungsstrategie hat die folgenden Parameter:

4.2.1 unsere

Dieser Parameter erzwingt, dass die Version des aktuellen Zweigs automatisch verwendet wird, wenn ein Konflikt auftritt. Diese Zusammenführungsmethode verursacht keine Probleme und selbst Git überprüft nicht den Konfliktinhalt in anderen Zweigversionen. Diese Methode verwirft jeglichen Konfliktinhalt im anderen Zweig.

4.2.2 Ihre

ist genau das Gegenteil von unserer.
Sowohl ihre als auch unsere Parameter eignen sich zum Zusammenführen von Binärdateikonflikten.

4.2.2 Geduld

Mit diesem Parameter verbringt git merge-recursive etwas mehr Zeit, um zu vermeiden, dass unwichtige Zeilen (z. B. Klammern von Funktionen) fehlen. Wenn der Abstand zwischen den Versionszweigen des aktuellen Zweigs und des anderen Zweigs sehr groß ist, wird empfohlen, diese Zusammenführungsmethode zu verwenden. git merge-recursive花费一些额外的时间来避免错过合并一些不重要的行（如函数的括号）。如果当前分支和对方分支的版本分支分离非常大时，建议采用这种合并方式。

4.2.3diff-algorithm=[patience|minimal|histogram|myers]

告知git merge-recursive使用不同的比较算法。

4.2.4 ignore-space-change, ignore-all-space, ignore-space-at-eol

根据指定的参数来对待空格冲突。

• 如果对方的版本仅仅添加了空格的变化，那么冲突合并时采用我们自己的版本
• 如果我们的版本含有空格，但是对方的版本包含大量的变化，那么冲突合并时采用对方的版本
• 采用正常的处理过程

4.2.5 no-renames

关闭重命名检测。

4.2.6subtree[=<path>]</path>

4.2.3 diff-algorithm=[patience|minimal|histogram|myers]

weist git merge-recursive an, einen anderen Vergleichsalgorithmus zu verwenden.

4.2.4 ignore-space-change, ignore-all-space, ignore-space-at-eol

Gemäß dem angegebene Parameter zur Behandlung von Leerraumkonflikten.

• Wenn die Version der anderen Partei nur Änderungen in Leerzeichen hinzufügt, wird unsere eigene Version beim Zusammenführen von Konflikten verwendet.
• Wenn unsere Version Leerzeichen enthält, die Version der anderen Partei jedoch eine große Zahl enthält von Änderungen. Verwenden Sie dann die Version der anderen Partei, wenn Sie Konflikte zusammenführen.
• Übernehmen Sie normale Verarbeitungsverfahren

4.2.5 keine Umbenennungen

Umbenennen deaktivieren Erkennung.

4.2.6subtree[=<path>]</path>

Diese Option ist eine erweiterte Form der Teilbaum-Zusammenführungsstrategie, die errät, wie sich die beiden Knotenbäume während des Zusammenführungsprozesses bewegen. Der Unterschied besteht darin, dass der angegebene Pfad zu Beginn der Zusammenführung entfernt wird, sodass bei der Suche nach Teilbäumen andere Pfade abgeglichen werden können. (Einzelheiten zur Teilbaum-Zusammenführungsstrategie finden Sie weiter unten.)

4.3octopus

Diese Zusammenführungsmethode wird für mehr als zwei Zweige verwendet, verweigert jedoch die Zusammenführung, wenn Konflikte eine manuelle Zusammenführung erfordern. Diese Zusammenführungsmethode eignet sich besser zum Bündeln mehrerer Zweige und ist auch die Standard-Zusammenführungsstrategie für Zusammenführungen mehrerer Zweige. 4.4ours

Diese Methode kann eine beliebige Anzahl von Zweigen zusammenführen, aber das zusammengeführte Ergebnis des Knotenbaums ist immer der widersprüchliche Teil des aktuellen Zweigs. Diese Methode kann beim Ersetzen älterer Versionen sehr effizient sein. Bitte beachten Sie, dass sich diese Methode vom ours-Parameter unter der rekursiven Strategie unterscheidet.

4.5subtree

subtree ist eine modifizierte Version der rekursiven Strategie. Wenn beim Zusammenführen von Baum A und Baum B B ein Teilbaum von A ist, passt sich B zunächst an die Baumstruktur von A an, anstatt denselben Knoten zu lesen. 🎜🎜4.5 Zusammenfassung🎜🎜Bei Verwendung der Drei-Wege-Merge-Strategie (bezogen auf die standardmäßige rekursive Strategie), wenn sich eine Datei (oder eine Codezeile) sowohl im aktuellen Zweig als auch im anderen Zweig ändert, später jedoch in einem zurückgesetzt wird der Filialen, 🎜Dann wird sich diese Fallback-Änderung in den Ergebnissen widerspiegeln🎜. Dieser Punkt könnte einige Leute verwirren. Dies liegt daran, dass sich Git während des Zusammenführungsprozesses nur auf den gemeinsamen Vorfahrenknoten und den HEAD-Knoten der beiden Zweige konzentriert und nicht auf alle Knoten der beiden Zweige. Daher betrachtet der Zusammenführungsalgorithmus den zurückgesetzten Teil als „unverändert“, sodass das zusammengeführte Ergebnis zum geänderten Teil des anderen Zweigs wird. 🎜🎜Empfohlenes Lernen: „🎜Git Tutorial🎜“🎜

Das obige ist der detaillierte Inhalt vonWas ist Merge in Git?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!