Synopsis
git add [-p] [-A] [-u] [--] [<pathspec>...]Description
The git add command moves changes from your working tree into the staging area (also called the index). The staging area is a snapshot of what will go into the next commit. By staging changes explicitly, Git lets you craft commits that contain exactly the work you want to record — even if your working tree has other unrelated edits in progress.
git add can stage entire files, parts of files (with -p), or directories. It does not commit anything; it only updates the index. The most common workflow is: edit, git status, git add, git commit. Mastering git add, especially its interactive modes, is one of the best ways to make your commit history readable and easy to review.
Dans l'usage quotidien, git add 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 --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 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 aide à éviter les trois.
Options courantes
| Option | Description |
|---|---|
-A, --all | Stager tous les changements de l'arborescence, y compris suppressions et nouveaux fichiers. |
-u, --update | Stager modifications et suppressions des fichiers suivis uniquement — ignore les nouveaux fichiers. |
-p, --patch | Choisir interactivement les hunks à stager. |
-n, --dry-run | Afficher ce qui serait stagé sans le stager réellement. |
-f, --force | Ajouter les fichiers même s'ils correspondent à .gitignore. |
-i, --interactive | Ouvrir une interface menu pour le staging. |
--intent-to-add / -N | Enregistrer l'intention d'ajouter un fichier pour que son diff apparaisse. |
Exemples
git add README.md src/main.c
# Stager deux fichiers spécifiques
git add -A
# Tout stager : nouveaux, modifiés, supprimés
git add -p
# Réviser interactivement et stager les chunks un par un
git add 'src/**/*.js'
# Stager tous les fichiers JS sous src via un pathspecErreurs fréquentes
Running git add . blindly often stages files you didn't intend — log files, build artifacts, secret keys. Use git status first and consider -p for sensitive changes. Another common confusion: git add -u will not pick up new files, while git add . will. After staging, if you change a file again, those subsequent edits are not staged until you re-run git add.
Commandes liées
git commit, git status, git restore, git reset