Übersicht

git send-email [--to <addr>] [--cc <addr>] [--cover-letter] <patch-or-dir>...

Beschreibung

Der git send-email-Befehl sendet einen oder mehrere Patches per SMTP, jeden als ordentlich verthreadete E-Mail. Es ist das kanonische Werkzeug zum Einreichen von Patches bei mailinglisten-getriebenen Projekten (Linux-Kernel, Git selbst, U-Boot usw.). Es kann SMTP-Credentials aus Ihrer Git-Konfiguration lesen, interaktiv abfragen oder Authentifizierungsdateien verwenden.

Patches werden der Reihe nach gesendet, mit In-Reply-To-Headern, die sie zu einem einzelnen Thread verbinden. Der Begleitbrief (falls vorhanden) wird zuerst als Eltern des Threads gesendet.

Im täglichen Einsatz integriert sich git send-email 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 send-email --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 send-email 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 send-email hilft, alle drei zu vermeiden.

Häufige Optionen

Option	Beschreibung
--to=<addr>	Hauptempfänger.
--cc=<addr>	Carbon Copy.
--smtp-server=<host>	SMTP-Server (oder sendmail-Pfad).
--smtp-user=<user>	SMTP-Benutzername.
--annotate	Erlaubt das Bearbeiten jedes Patches vor dem Senden.
--dry-run	Zeigt, was gesendet würde.
--in-reply-to=<message-id>	Threadet unter eine bestehende Nachricht.
--confirm=<mode>	Bestätigungs-Verhalten (always, never, cc).

Beispiele

git send-email [email protected] *.patch
    # Alle Patches im aktuellen Verzeichnis an eine Liste senden

    git send-email --cover-letter [email protected] \
      [email protected] 0001-*.patch
    # Serie mit Begleitbrief, Hauptempfänger + cc

    git send-email --dry-run --annotate -1 HEAD
    # Vorschau eines einzelnen Patches ohne Senden

    git config --global sendemail.smtpServer smtp.gmail.com
    git config --global sendemail.smtpServerPort 587
    git config --global sendemail.smtpEncryption tls
    # Einmalige SMTP-Konfiguration

Häufige Fehler

Viele Unternehmens-SMTP-Server blockieren reines SMTP — verwenden Sie TLS oder app-spezifische Passwörter. Vergessen, --cover-letter beim Senden einer Multi-Patch-Serie hinzuzufügen, lässt Reviewer ohne Kontext. Eine Re-Roll ohne --in-reply-to auf den ursprünglichen Begleitbrief fragmentiert die Diskussion.

Verwandte Befehle

git format-patch, git am, git request-pull, git config