Synopsis
git add -p [<path>...]
git add --patch [<path>...]
Description
The git add -p command launches an interactive interface that walks through each "hunk" of changes in your working tree, asking you to decide for each: stage, skip, split, edit, etc. This is the secret weapon for crafting clean, atomic commits when your working tree contains a mixture of related and unrelated changes.
The interactive prompt accepts single-letter commands: y (yes, stage this hunk), n (no, skip), s (split into smaller hunks), e (edit the hunk manually), q (quit), ? (help), and several others. Mastering add -p is one of the highest-leverage skills for producing reviewable history.
Dans l'usage quotidien, git add -p 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 add -p --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 add -p 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 add -p aide à éviter les trois.
Options courantes
| Interactive command | Description |
|---|---|
y | Stage this hunk. |
n | Don't stage this hunk. |
s | Split into smaller hunks. |
e | Manually edit the hunk. |
a | Stage this and all remaining hunks in this file. |
d | Skip this and all remaining hunks in this file. |
q | Quit; don't stage further hunks. |
? | Show help. |
Exemples
git add -p
# Walk through every changed file's hunks
git add -p src/auth.go
# Restrict to one file
# Inside the prompt:
# Press 's' to split a large hunk into smaller ones
# Press 'e' to manually edit the hunk text
# Press 'y' or 'n' to accept or skip
git diff --cached
# Review what's now staged
Erreurs fréquentes
Editing a hunk with e requires understanding the unified diff format — adding a line means the new file has it, removing a context line means the new file lacks it. Mistakes here can produce confusing index state. Always verify with git diff --cached after.
Commandes liées
git add, git stash -p, git restore -p, git checkout -p