Übersicht

git format-patch [<options>] <range>
git format-patch -1 <commit>

Beschreibung

Der git format-patch-Befehl erzeugt eine Mailbox-formatierte Patch-Datei pro Commit in einem Bereich, bereit zum Anwenden mit git am oder zum Versenden mit git send-email. Jeder Patch enthält die Commit-Nachricht, den Autor, das Datum und den Diff. Patches sind nummeriert (0001-..., 0002-...), sodass sie der Reihe nach angewendet werden.

Das ist das Format, das der Linux-Kernel und viele Open-Source-Projekte für Code-Review auf Mailinglisten verwenden. Selbst Projekte, die Pull Requests verwenden, akzeptieren manchmal Patches per E-Mail, und format-patch ist der Standard-Erzeuger.

Im täglichen Einsatz integriert sich git format-patch eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git format-patch --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.

Zu verstehen, wie git format-patch mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git format-patch hilft, alle drei zu vermeiden.

Häufige Optionen

Option	Beschreibung
-<n>	Erzeugt Patches für die letzten n Commits.
-o <dir>	Schreibt Patches in ein Verzeichnis.
--cover-letter	Erzeugt einen 0000-Begleitbrief für die Serie.
-v <n>, --reroll-count=<n>	Markiert Patches als n-te Iteration.
--subject-prefix=<prefix>	Eigenes Betreff-Präfix (Standard PATCH).
--to=<addr> / --cc=<addr>	Empfänger in Headern hinzufügen.
--thread	Fügt In-Reply-To-Header hinzu.

Beispiele

git format-patch -3
    # Patches für die letzten 3 Commits, im aktuellen Verzeichnis

    git format-patch -o ../patches main..feature
    # Patches von main bis feature, nach ../patches/

    git format-patch --cover-letter -v2 origin/main
    # Versionierte Serie mit Begleitbrief

    git format-patch --subject-prefix="PATCH myproj" -1 HEAD
    # Eigener Betreff für eine projektspezifische Liste

Häufige Fehler

Patches gegen die falsche Basis zu erzeugen produziert Apply-Fehler für Reviewer — wählen Sie den richtigen Upstream. Ohne --cover-letter hat eine Multi-Patch-Serie keine Einleitung; Reviewer schätzen eine. Reroll ohne -v erzeugt Mehrdeutigkeit, welche Version reviewt wird.

Verwandte Befehle

git am, git send-email, git request-pull, git range-diff