Führt den Merge durch und committet das Ergebnis. Diese Option kann verwendet werden, um --no-commit zu überschreiben.

Ruft einen Editor auf, bevor ein erfolgreicher mechanischer Merge committet wird, um die automatisch generierte Merge-Nachricht weiter zu bearbeiten, damit der Benutzer den Merge erklären und begründen kann. Die Option --no-edit kann verwendet werden, um die automatisch generierte Nachricht zu akzeptieren (dies wird im Allgemeinen nicht empfohlen). Die Option --edit (oder -e) ist immer noch nützlich, wenn Sie mit der Option -m von der Kommandozeile aus eine Entwurfsnachricht angeben und diese im Editor bearbeiten möchten.

Diese Option bestimmt, wie die Merge-Nachricht vor dem Commit bereinigt wird. Weitere Einzelheiten finden Sie in git-commit[1]. Wenn dem <mode> zusätzlich der Wert scissors gegeben wird, werden Scheren an MERGE_MSG angehängt, bevor sie an die Commit-Mechanik im Falle eines Merge-Konflikts weitergegeben werden.

Gibt an, wie ein Merge behandelt wird, wenn die gemergte Historie bereits ein Nachfahre der aktuellen Historie ist. --ff ist der Standard, es sei denn, ein annotierter (und möglicherweise signierter) Tag wird gemergt, der sich nicht an seinem natürlichen Platz in der refs/tags/ Hierarchie befindet, in diesem Fall wird --no-ff angenommen.

Signiert den resultierenden Merge-Commit mit GPG. Das Argument <key-id> ist optional und standardmäßig die Kommitteur-Identität; wenn es angegeben wird, muss es ohne Leerzeichen an die Option angehängt werden. --no-gpg-sign ist nützlich, um sowohl die Konfigurationsvariable commit.gpgSign als auch frühere --gpg-sign-Aufrufe zu überschreiben.

Zusätzlich zu den Branch-Namen werden die Log-Nachricht mit einzeiligen Beschreibungen von höchstens <n> tatsächlich gemergten Commits gefüllt. Siehe auch git-fmt-merge-msg[1].

Fügt einen Signed-off-by-Trailer vom Committer am Ende der Commit-Log-Nachricht hinzu. Die Bedeutung eines Sign-offs hängt vom Projekt ab, an das Sie committen. Es kann beispielsweise bestätigen, dass der Committer die Rechte hat, die Arbeit unter der Lizenz des Projekts einzureichen, oder einer bestimmten Beitragsstellervereinbarung zustimmt, wie z. B. einem Developer Certificate of Origin. (Siehe https://developercertificate.org für das von den Linux-Kernel- und Git-Projekten verwendete.) Konsultieren Sie die Dokumentation oder die Führung des Projekts, zu dem Sie beitragen, um zu verstehen, wie die Sign-offs in diesem Projekt verwendet werden.

Zeigt am Ende des Merges einen Diffstat an. Der Diffstat wird auch durch die Konfigurationsoption merge.stat gesteuert.

Zeigt am Ende des Merges eine kompakte Zusammenfassung an.

Produziert den Arbeitsbaum und den Index so, als wäre ein echter Merge erfolgt (außer der Merge-Information), aber ohne tatsächlich einen Commit zu machen, HEAD zu bewegen oder $GIT_DIR/MERGE_HEAD aufzuzeichnen (damit der nächste git commit Befehl einen Merge-Commit erstellt). Dies ermöglicht es Ihnen, einen einzigen Commit auf dem aktuellen Branch zu erstellen, dessen Effekt dem Mergen eines anderen Branches entspricht (oder mehr im Falle eines Oktopus).

Standardmäßig werden die Hooks `pre-merge` und `commit-msg` ausgeführt. Wenn --no-verify angegeben wird, werden diese umgangen. Siehe auch githooks[5].

Verwendet die angegebene Merge-Strategie; kann mehrfach angegeben werden, um sie in der Reihenfolge zu spezifizieren, in der sie versucht werden sollen. Wenn keine -s-Option angegeben ist, wird stattdessen eine eingebaute Liste von Strategien verwendet (ort beim Mergen eines einzelnen Heads, octopus andernfalls).

Übergibt strategie-spezifische Optionen an die Merge-Strategie.

Überprüft, ob der Spitzen-Commit des zu mergenden Seiten-Branches mit einem gültigen Schlüssel signiert ist, d.h. einem Schlüssel mit einer gültigen uid: im Standard-Vertrauensmodell wurde der Signierschlüssel von einem vertrauenswürdigen Schlüssel signiert. Wenn der Spitzen-Commit des Seiten-Branches nicht mit einem gültigen Schlüssel signiert ist, wird der Merge abgebrochen.

Synonyme für --stat und --no-stat; diese sind veraltet und werden in Zukunft entfernt.

Arbeitet im Stillen. Impliziert --no-progress.

Ausführlich sein.

Schaltet die Fortschrittsanzeige explizit ein/aus. Wenn keine der beiden Optionen angegeben ist, wird der Fortschritt angezeigt, wenn Standardfehler mit einem Terminal verbunden ist. Beachten Sie, dass möglicherweise nicht alle Merge-Strategien Fortschrittsberichte unterstützen.

Erstellt automatisch einen temporären Stash-Eintrag, bevor die Operation beginnt, zeichnet ihn im Ref MERGE_AUTOSTASH auf und wendet ihn nach Abschluss der Operation an. Das bedeutet, dass Sie die Operation auf einem schmutzigen Arbeitsbaum ausführen können. Vorsicht: Das abschließende Anwenden des Stashes nach einem erfolgreichen Merge kann zu nicht-trivialen Konflikten führen.

Standardmäßig lehnt der Befehl git merge das Mergen von Historien ab, die keinen gemeinsamen Vorfahren haben. Diese Option kann verwendet werden, um diese Sicherheit zu umgehen, wenn Historien von zwei Projekten gemergt werden, die ihr Leben unabhängig begonnen haben. Da dies ein sehr seltener Fall ist, gibt es keine Konfigurationsvariable, um dies standardmäßig zu aktivieren, und es wird auch keine hinzugefügt werden.

Setzt die Commit-Nachricht, die für den Merge-Commit verwendet werden soll (falls einer erstellt wird).

Bereitet die Standard-Merge-Nachricht so vor, als würde in den Branch <branch> gemergt, anstatt in den Namen des tatsächlichen Branches, in den gemergt wird.

Liest die Commit-Nachricht, die für den Merge-Commit verwendet werden soll (falls einer erstellt wird).

Nachdem der rerere-Mechanismus eine aufgezeichnete Auflösung für den aktuellen Konflikt wiederverwendet hat, um die Dateien im Arbeitsbaum zu aktualisieren, erlauben Sie ihm auch, den Index mit dem Ergebnis der Auflösung zu aktualisieren. --no-rerere-autoupdate ist eine gute Möglichkeit, zu überprüfen, was rerere getan hat, und potenzielle Fehlmerges zu erkennen, bevor das Ergebnis mit einem separaten git add in den Index übernommen wird.

Überschreibt ignorierte Dateien aus dem Merge-Ergebnis stillschweigend. Dies ist das Standardverhalten. Verwenden Sie --no-overwrite-ignore zum Abbrechen.

Bricht den aktuellen Konfliktlösungs-Prozess ab und versucht, den Zustand vor dem Merge wiederherzustellen. Wenn ein Autostash-Eintrag vorhanden ist, wird er auf den Arbeitsbaum angewendet.

Vergessen Sie den aktuellen Merge-Vorgang. Lassen Sie den Index und den Arbeitsbaum unverändert. Wenn MERGE_AUTOSTASH vorhanden ist, wird der Stash-Eintrag in der Stash-Liste gespeichert.

Nachdem git merge aufgrund von Konflikten gestoppt wurde, können Sie den Merge abschließen, indem Sie git merge --continue ausführen (siehe unten den Abschnitt "WIE KONFLIKTE GELÖST WERDEN").

Commits, normalerweise andere Branch-Heads, die in unseren Branch gemergt werden sollen. Die Angabe von mehr als einem Commit erstellt einen Merge mit mehr als zwei Eltern (liebevoll ein Oktopus-Merge genannt).

Dies ist die Standard-Merge-Strategie beim Ziehen oder Zusammenführen eines Zweigs. Diese Strategie kann nur zwei Köpfe mithilfe eines 3-Wege-Merge-Algorithmus auflösen. Wenn es mehr als einen gemeinsamen Vorfahren gibt, der für einen 3-Wege-Merge verwendet werden kann, erstellt sie einen zusammengeführten Baum der gemeinsamen Vorfahren und verwendet diesen als Referenzbaum für den 3-Wege-Merge. Dies hat Berichten zufolge zu weniger Merge-Konflikten geführt, ohne Fehl-Merges zu verursachen, basierend auf Tests mit tatsächlichen Merge-Commits aus der Linux 2.6 Kernel-Entwicklungshistorie. Zusätzlich kann diese Strategie Renames erkennen und handhaben. Sie nutzt keine erkannten Kopien. Der Name für diesen Algorithmus ist ein Akronym ("Ostensibly Recursive’s Twin") und stammt daher, dass er als Ersatz für den bisherigen Standardalgorithmus recursive geschrieben wurde.

Dies ist jetzt ein Synonym für ort. Es war bis v2.49.0 eine alternative Implementierung, wurde aber ab v2.50.0 auf ort umgeleitet. Die frühere rekursive Strategie war die Standardstrategie zur Auflösung von zwei Köpfen von Git v0.99.9k bis v2.33.0.

Dies kann nur zwei Köpfe (d. h. den aktuellen Zweig und einen anderen, von dem Sie gezogen haben) mithilfe eines 3-Wege-Merge-Algorithmus auflösen. Es versucht, Mehrdeutigkeiten bei Kreuz-Merges sorgfältig zu erkennen. Es verarbeitet keine Renames.

Dies löst Fälle mit mehr als zwei Köpfen, lehnt jedoch komplexe Merges ab, die eine manuelle Auflösung erfordern. Er ist hauptsächlich dafür gedacht, Topic-Zweig-Köpfe zu bündeln. Dies ist die Standard-Merge-Strategie, wenn mehr als ein Zweig gezogen oder zusammengeführt wird.

Dies löst eine beliebige Anzahl von Köpfen auf, aber der resultierende Baum des Merges ist immer der des aktuellen Zweigkopfs, wodurch alle Änderungen von allen anderen Zweigen effektiv ignoriert werden. Er ist dafür gedacht, alte Entwicklungshistorien von Seitenästen zu ersetzen. Beachten Sie, dass dies sich von der Option -Xours für die ort-Merge-Strategie unterscheidet.

Dies ist eine modifizierte ort-Strategie. Beim Zusammenführen der Bäume A und B, wenn B einem Unterverzeichnis von A entspricht, wird B zuerst angepasst, um der Baumstruktur von A zu entsprechen, anstatt die Bäume auf derselben Ebene zu lesen. Diese Anpassung erfolgt auch für den gemeinsamen Vorfahrenbaum.

Legt Standardoptionen für das Zusammenführen in Zweig <name> fest. Die Syntax und die unterstützten Optionen sind die gleichen wie bei git merge, aber Optionswerte, die Leerzeichen enthalten, werden derzeit nicht unterstützt.

Gibt den Stil an, in dem widersprüchliche Hunks beim Zusammenführen in Arbeitsbaumdateien geschrieben werden. Der Standard ist "merge", der eine <<<<<<<-Konfliktmarkierung, Änderungen einer Seite, eine =======-Markierung, Änderungen der anderen Seite und dann eine >>>>>>>-Markierung anzeigt. Ein alternativer Stil, "diff3", fügt eine |||||||-Markierung und den ursprünglichen Text vor der =======-Markierung hinzu. Der "merge"-Stil neigt dazu, kleinere Konfliktregionen als diff3 zu erzeugen, sowohl aufgrund des Ausschlusses des ursprünglichen Textes als auch weil, wenn ein Teil der Zeilen auf beiden Seiten übereinstimmt, sie einfach aus der Konfliktregion herausgezogen werden. Ein weiterer alternativer Stil, "zdiff3", ist ähnlich wie diff3, entfernt aber übereinstimmende Zeilen auf beiden Seiten aus der Konfliktregion, wenn diese übereinstimmenden Zeilen nahe dem Anfang oder Ende einer Konfliktregion erscheinen.

Wenn merge ohne Commit-Argument aufgerufen wird, werden die für den aktuellen Zweig konfigurierten Upstream-Zweige anhand ihrer zuletzt beobachteten Werte, die in ihren Remote-Tracking-Zweigen gespeichert sind, zusammengeführt. Die Werte von branch.<current branch>.merge, die die Zweige unter dem von branch.<current-branch>.remote benannten Namen angeben, werden konsultiert und dann über remote.<remote>.fetch ihren entsprechenden Remote-Tracking-Zweigen zugeordnet, und die Spitzen dieser Tracking-Zweige werden zusammengeführt. Standardmäßig ist dies true.

Standardmäßig erstellt Git keinen zusätzlichen Merge-Commit, wenn ein Commit zusammengeführt wird, der ein Nachkomme des aktuellen Commits ist. Stattdessen wird die Spitze des aktuellen Zweigs durchgeschaltet (fast-forward). Wenn dieser Wert auf false gesetzt ist, weist diese Variable Git an, in einem solchen Fall einen zusätzlichen Merge-Commit zu erstellen (entspricht der Angabe der Option --no-ff auf der Befehlszeile). Wenn dieser Wert auf only gesetzt ist, sind nur solche Fast-Forward-Merges zulässig (entspricht der Angabe der Option --ff-only auf der Befehlszeile).

Wenn true, ist dies äquivalent zur Befehlszeilenoption --verify-signatures. Siehe git-merge[1] für Details.

Befüllt zusätzlich zu den Zweignamen die Log-Nachricht mit dem zugehörigen Beschriftungstext des Zweigs. Standardmäßig false.

Befüllt zusätzlich zu den Zweignamen die Log-Nachricht mit höchstens der angegebenen Anzahl von Einzeilenbeschreibungen aus den tatsächlich zusammengeführten Commits. Standardmäßig false, und true ist ein Synonym für 20.

Durch Hinzufügen eines Glob-Musters, das die Namen von Integrationszweigen übereinstimmt, zu dieser mehrwertigen Konfigurationsvariablen wird die für Merges in diese Integrationszweige berechnete Standard-Merge-Nachricht "into <branch-name>" aus ihrem Titel weglassen.

Die Anzahl der Dateien, die im erschöpfenden Teil der Rename-Erkennung während eines Merges berücksichtigt werden. Wenn nicht angegeben, wird der Wert von diff.renameLimit verwendet. Wenn weder merge.renameLimit noch diff.renameLimit angegeben sind, beträgt der Standardwert derzeit 7000. Diese Einstellung hat keine Auswirkung, wenn die Rename-Erkennung deaktiviert ist.

Ob Git Renames erkennt. Wenn auf false gesetzt, ist die Rename-Erkennung deaktiviert. Wenn auf true gesetzt, ist die grundlegende Rename-Erkennung aktiviert. Standardmäßig wird der Wert von diff.renames verwendet.

Ob Git Verzeichnis-Renames erkennt, was sich darauf auswirkt, was zum Zeitpunkt des Merges mit neuen Dateien geschieht, die einem Verzeichnis auf einer Seite der Historie hinzugefügt wurden, während dieses Verzeichnis auf der anderen Seite der Historie umbenannt wurde. Mögliche Werte sind:

Teilt Git mit, dass sich die kanonische Darstellung von Dateien im Repository im Laufe der Zeit geändert hat (z. B. frühere Commits speichern Textdateien mit CRLF-Zeilenenden, aber neuere verwenden LF-Zeilenenden). In einem solchen Repository kann Git für jede Datei, bei der ein 3-Wege-Inhalts-Merge erforderlich ist, die in Commits gespeicherten Daten vor dem Merge in eine kanonische Form konvertieren, um unnötige Konflikte zu reduzieren. Weitere Informationen finden Sie im Abschnitt "Merging branches with differing checkin/checkout attributes" in gitattributes[5].

Was, wenn überhaupt, zwischen ORIG_HEAD und dem Merge-Ergebnis am Ende des Merges gedruckt werden soll. Mögliche Werte sind:

Wenn dies auf true gesetzt ist, wird vor Beginn des Vorgangs automatisch ein temporärer Stash-Eintrag erstellt und nach Abschluss des Vorgangs angewendet. Das bedeutet, dass Sie einen Merge auf einem nicht bereinigten Arbeitsbaum ausführen können. Verwenden Sie dies jedoch mit Vorsicht: das abschließende Anwenden des Stashs nach einem erfolgreichen Merge kann zu nicht trivialen Konflikten führen. Diese Option kann durch die Optionen --no-autostash und --autostash von git-merge[1] überschrieben werden. Standardmäßig ist sie false.

Steuert, welcher Merge-Tool von git-mergetool[1] verwendet wird. Die folgende Liste zeigt die gültigen integrierten Werte. Jeder andere Wert wird als benutzerdefiniertes Merge-Tool behandelt und erfordert die Definition einer entsprechenden Variablen mergetool.<tool>.cmd.

Steuert, welcher Merge-Tool von git-mergetool[1] verwendet wird, wenn das Flag -g/--gui angegeben ist. Die folgende Liste zeigt die gültigen integrierten Werte. Jeder andere Wert wird als benutzerdefiniertes Merge-Tool behandelt und erfordert die Definition einer entsprechenden Variablen mergetool.<guitool>.cmd.

Steuert die Menge der vom rekursiven Merge-Algorithmus angezeigten Ausgaben. Stufe 0 gibt nichts aus, außer einer abschließenden Fehlermeldung, wenn Konflikte erkannt wurden. Stufe 1 gibt nur Konflikte aus, Stufe 2 gibt Konflikte und Dateiänderungen aus. Stufe 5 und höher gibt Debugging-Informationen aus. Der Standard ist Stufe 2. Kann durch die Umgebungsvariable GIT_MERGE_VERBOSITY überschrieben werden.

Definiert einen lesbaren Namen für einen benutzerdefinierten Low-Level-Merge-Treiber. Siehe gitattributes[5] für Details.

Definiert den Befehl, der einen benutzerdefinierten Low-Level-Merge-Treiber implementiert. Siehe gitattributes[5] für Details.

Benennt einen Low-Level-Merge-Treiber, der bei der internen Zusammenführung zwischen gemeinsamen Vorfahren verwendet wird. Siehe gitattributes[5] für Details.