Synopsis
git send-email [--to <addr>] [--cc <addr>] [--cover-letter] <patch-or-dir>...Description
The git send-email command sends one or more patches via SMTP, each as a properly threaded email. It is the canonical tool for submitting patches to mailing-list-driven projects (Linux kernel, Git itself, U-Boot, etc.). It can read SMTP credentials from your Git config, prompt for them interactively, or use authentication files.
Patches are sent in order, with In-Reply-To headers connecting them into a single thread. The cover letter (if present) is sent first as the parent of the thread.
Dans l'usage quotidien, git send-email s'intègre étroitement avec les alias de shell, les plugins d'éditeur et l'intégration continue. Les utilisateurs avancés ajoutent souvent des alias combinant les flags qu'ils passent toujours, ou enveloppent la commande dans des scripts qui appliquent les conventions d'équipe. Le formatage de la sortie peut être personnalisé via la configuration Git — pretty formats, schémas de couleurs et comportement du pager sont tous ajustables. Quand quelque chose tourne mal, la première étape de diagnostic est généralement de relancer la commande avec GIT_TRACE=1 dans l'environnement, ce qui révèle les appels de plomberie sous-jacents. Pour les situations inhabituelles, la sortie --help (git send-email --help) ouvre la page de manuel complète avec les détails de chaque option, y compris celles rarement utilisées dans les workflows ordinaires mais essentielles pour le débogage ou le scripting à grande échelle.
Comprendre comment git send-email interagit avec le reste du modèle de données de Git — la base d'objets, l'index, les refs et l'arborescence de travail — est rentable. Chaque commande opère sur un sous-ensemble de ces pièces, et savoir laquelle elle touche aide à prédire les résultats et récupérer après les erreurs. Lire la documentation officielle de Git en parallèle de la pratique sur un dépôt jetable est la façon la plus rapide d'intérioriser les subtilités. La plupart des problèmes de production avec Git proviennent de l'une de trois causes : comportement par défaut surprenant, opérations réseau partielles, ou réécriture d'historique déjà partagé. Un modèle mental fonctionnel des effets de bord de git send-email aide à éviter les trois.
Options courantes
| Option | Description |
|---|---|
--to=<addr> | Primary recipient. |
--cc=<addr> | Carbon copy. |
--smtp-server=<host> | SMTP server (or sendmail path). |
--smtp-user=<user> | SMTP username. |
--annotate | Allow editing each patch before sending. |
--dry-run | Show what would be sent. |
--in-reply-to=<message-id> | Thread under an existing message. |
--confirm=<mode> | Confirmation behavior (always, never, cc). |
Exemples
git send-email [email protected] *.patch
# Send all patches in CWD to a list
git send-email --cover-letter [email protected] \
[email protected] 0001-*.patch
# Series with cover letter, primary + cc
git send-email --dry-run --annotate -1 HEAD
# Preview a single patch without sending
git config --global sendemail.smtpServer smtp.gmail.com
git config --global sendemail.smtpServerPort 587
git config --global sendemail.smtpEncryption tls
# One-time SMTP configurationErreurs fréquentes
Many corporate SMTP servers block plain SMTP — use TLS or app-specific passwords. Forgetting --cover-letter when sending a multi-patch series leaves reviewers without context. Sending a re-roll without --in-reply-to the original cover letter fragments the discussion.
Commandes liées
git format-patch, git am, git request-pull, git config