Staging interactif avec git add -p

git add -p vous permet de choisir quelles lignes vont dans le prochain commit, hunk par hunk. Au lieu de stager un fichier entier, vous sélectionnez précisément les modifications pertinentes. C’est l’outil essentiel pour des commits atomiques et un historique propre.

Prérequis : Enregistrer des modifications et Sélection de révisions.

Ce que vous allez apprendre

Utiliser git add -p pour fragmenter vos modifications en commits atomiques
Éditer un hunk manuellement quand les découpages automatiques ne conviennent pas
Désindexer sélectivement avec git reset -p
Produire des commits propres qui passent la revue de code sans friction

Pourquoi le staging partiel ?

Vous travaillez sur un fichier et vous avez fait deux changements indépendants : un correctif de bug et un refactoring. Committer les deux ensemble produit un commit confus. Le staging interactif résout ce problème :

Commits atomiques : chaque commit contient un seul changement logique
Historique lisible : facilite le git bisect et le code review
Réversibilité : un commit ciblé se revert sans dommage collatéral

`git add -p` : le mode patch

La commande la plus utilisée. Elle parcourt chaque « hunk » (bloc de modifications) et vous demande quoi en faire :

git add -p

Git affiche chaque hunk avec un prompt :

@@ -10,6 +10,8 @@ def calculate_price(quantity, unit_price):
     total = quantity * unit_price
+    # Appliquer la remise si > 100 articles
+    if quantity > 100:
+        total *= 0.9
     return total

(1/3) Stage this hunk [y,n,q,a,d,s,e,?]?

Les options du prompt

Option	Action
`y`	Yes — stager ce hunk
`n`	No — ignorer ce hunk
`q`	Quit — quitter (les hunks déjà stagés le restent)
`a`	All — stager ce hunk et tous les suivants du fichier
`d`	Don’t — ignorer ce hunk et tous les suivants du fichier
`s`	Split — découper en hunks plus petits
`e`	Edit — éditer manuellement le hunk
`?`	Afficher l’aide

Workflow typique

Modifiez un fichier avec plusieurs changements logiquement distincts.
Lancez le staging interactif :
Fenêtre de terminal
```
git add -p fichier.py
```
Pour chaque hunk, répondez y (stager) ou n (ignorer).
Commitez les modifications stagées :
Fenêtre de terminal
```
git commit -m "fix: corriger le calcul de remise"
```

Recommencez git add -p pour le changement suivant :

git add -p fichier.py
git commit -m "refactor: extraire la fonction de remise"

Découper un hunk avec `s` (split)

Si un hunk contient des modifications trop proches, s le découpe en sous-blocs. Git peut splitter uniquement si des lignes non modifiées séparent les changements :

Stage this hunk [y,n,q,a,d,s,e,?]? s
Split into 2 hunks.

Si s ne peut pas splitter davantage (modifications sur des lignes adjacentes), utilisez e pour éditer manuellement.

Éditer un hunk avec `e` (edit)

L’option e ouvre le hunk dans votre éditeur. Vous pouvez alors supprimer des lignes + que vous ne voulez pas stager :

# Manual hunk edit mode
# Pour retirer une ligne ajoutée du staging : supprimez la ligne
# Pour garder une ligne supprimée : remplacez - par un espace
@@ -10,6 +10,8 @@
     total = quantity * unit_price
+    # Appliquer la remise si > 100 articles
+    if quantity > 100:
+        total *= 0.9
     return total

Règles d’édition :

Pour ne pas stager une ligne + : supprimez toute la ligne
Pour ne pas stager une ligne - : remplacez le - par un espace (la ligne reste dans le fichier de travail)
Ne modifiez jamais les lignes de contexte (sans préfixe)

`git add -i` : le mode interactif complet

git add -i donne un menu plus complet que -p :

git add -i

           staged     unstaged path
  1:    unchanged        +3/-1 src/app.py
  2:    unchanged        +1/-0 src/config.py

*** Commands ***
  1: status     2: update     3: revert     4: add untracked
  5: patch      6: diff       7: quit       8: help
What now>

Commande	Équivalent
`update`	Stager des fichiers entiers
`revert`	Désélectionner des fichiers stagés
`patch`	Identique à `git add -p`
`diff`	Voir le diff stagé
`add untracked`	Stager des fichiers non suivis

En pratique, git add -p suffit dans la grande majorité des cas. Le mode -i est utile quand vous avez beaucoup de fichiers modifiés et voulez un aperçu global.

`git reset -p` : désélectionner par hunks

L’inverse de git add -p. Si vous avez stagé trop de modifications :

git reset -p

Le même prompt apparaît, mais cette fois y retire le hunk du staging (le remet dans le working directory).

# Équivalent moderne
git restore --staged -p fichier.py

`git checkout -p` et `git stash -p`

Le mode patch fonctionne aussi avec d’autres commandes :

# Annuler des modifications par hunks (working directory)
git checkout -p fichier.py
# Moderne :
git restore -p fichier.py

# Stasher seulement certains hunks
git stash -p

Dépannage

Symptôme	Cause probable	Solution
`patch does not apply`	Édition manuelle incorrecte	Recommencez, respectez les règles d’édition
`s` ne découpe pas	Modifications sur lignes adjacentes	Utilisez `e` pour éditer manuellement
Hunk trop gros	Nombreuses modifications groupées	`s` puis `e` si nécessaire
Modifications perdues après `-p`	Hunk répondu `n` toujours dans le working dir	Normal : `n` = pas stagé, pas supprimé

À retenir

git add -p stage par hunks — l’outil clé pour des commits atomiques
y/n pour accepter/refuser, s pour découper, e pour éditer
git reset -p fait l’inverse : retire du staging hunk par hunk
Le mode patch fonctionne aussi avec checkout, stash et restore
Des commits atomiques facilitent le bisect, le revert et le code review
Avant de commiter, vérifiez ce qui est exactement dans l’index : git diff --staged

Prochaines étapes

Stashing et cleaning Mettez de côté vos modifications temporairement avec git stash.

Réécrire l'historique Réorganisez vos commits avec rebase interactif.

Reset démystifié Comprenez les 3 arbres et les modes --soft, --mixed, --hard.