Toutes les Commandes Git : Aide-Mémoire Complet avec Exemples 🔀
↩️ Voir toutes les fiches programmation & outils
🔀 En bref
Git est le système de contrôle de version utilisé par quasiment tous les développeurs dans le monde. Il permet de suivre les modifications de votre code, de revenir en arrière, de travailler à plusieurs et de gérer des branches de développement parallèles. Cette fiche regroupe toutes les commandes Git essentielles, classées par usage, avec la syntaxe complète et des exemples concrets prêts à copier-coller dans votre terminal.
Sommaire
- Configuration initiale
- Créer et cloner un dépôt
- Commandes de base (add, commit, status)
- Branches (créer, changer, supprimer)
- Dépôts distants (push, pull, fetch)
- Historique et inspection (log, diff, blame)
- Annuler et corriger (reset, revert, stash)
- Fusionner et rebaser (merge, rebase)
- Tags et versions
- Commandes avancées
- Le workflow Git en 5 étapes
- .gitignore : les fichiers à ignorer
- Questions fréquentes
Configuration initiale ⚙️
Avant d’utiliser Git, vous devez configurer votre identité. Ces informations seront associées à chacun de vos commits.
| Commande | Description |
|---|---|
| git config –global user.name « Votre Nom » | Définit votre nom pour tous les dépôts |
| git config –global user.email « email@exemple.com » | Définit votre email pour tous les dépôts |
| git config –global init.defaultBranch main | Utilise « main » au lieu de « master » par défaut |
| git config –global core.editor « code –wait » | Définit VS Code comme éditeur par défaut |
| git config –list | Affiche toute la configuration actuelle |
💡 Astuce : Le flag --global applique la configuration à tous vos dépôts. Sans ce flag, la configuration ne s’applique qu’au dépôt courant (utile si vous avez un email pro et un email perso).
Créer et cloner un dépôt 📁
Deux manières de démarrer avec Git : créer un nouveau dépôt ou copier un dépôt existant.
| Commande | Description |
|---|---|
| git init | Crée un nouveau dépôt Git dans le dossier courant |
| git init mon-projet | Crée un nouveau dossier avec un dépôt Git à l’intérieur |
| git clone URL | Clone un dépôt distant (GitHub, GitLab…) en local |
| git clone URL mon-dossier | Clone dans un dossier au nom personnalisé |
| git clone –depth 1 URL | Clone uniquement le dernier commit (plus rapide) |
Exemple concret :
# Créer un nouveau projet
mkdir mon-projet && cd mon-projet
git init
# OU cloner un projet existant depuis GitHub
git clone https://github.com/utilisateur/projet.git
cd projet
Commandes de base ✅
Le cœur du workflow Git : vérifier l’état, ajouter des fichiers et créer des commits.
| Commande | Description |
|---|---|
| git status | Affiche l’état des fichiers (modifiés, stagés, non suivis) |
| git add fichier.txt | Ajoute un fichier précis à la zone de staging |
| git add . | Ajoute tous les fichiers modifiés et nouveaux |
| git add -p | Ajoute interactivement (choisir quels changements stager) |
| git commit -m « message » | Crée un commit avec un message |
| git commit -am « message » | Ajoute les fichiers suivis modifiés ET commit en une seule commande |
| git commit –amend | Modifie le dernier commit (message ou contenu) |
| git rm fichier.txt | Supprime un fichier et stage la suppression |
| git rm –cached fichier.txt | Retire un fichier du suivi Git sans le supprimer du disque |
| git mv ancien.txt nouveau.txt | Renomme un fichier (suivi par Git) |
Exemple concret :
# Le workflow de base
git status # voir ce qui a changé
git add . # tout stager
git commit -m "Ajout page contact" # commiter
# Corriger le dernier commit (avant push)
git add fichier-oublie.txt
git commit --amend --no-edit # ajoute le fichier au commit précédent
⚠️ Attention : git commit --amend réécrit l’historique. Ne l’utilisez que sur des commits qui n’ont PAS encore été pushés. Modifier un commit déjà pushé crée des conflits pour les autres développeurs.
Branches 🌿
Les branches permettent de travailler sur plusieurs fonctionnalités en parallèle sans toucher à la branche principale.
| Commande | Description |
|---|---|
| git branch | Liste toutes les branches locales |
| git branch -a | Liste toutes les branches (locales + distantes) |
| git branch nom-branche | Crée une nouvelle branche |
| git branch -d nom-branche | Supprime une branche (si déjà fusionnée) |
| git branch -D nom-branche | Supprime une branche (forcer, même non fusionnée) |
| git branch -m nouveau-nom | Renomme la branche courante |
| git switch nom-branche | Change de branche (méthode moderne) |
| git switch -c nom-branche | Crée une branche ET bascule dessus |
| git checkout nom-branche | Change de branche (méthode classique) |
| git checkout -b nom-branche | Crée une branche ET bascule dessus (classique) |
Exemple concret :
# Créer une branche pour une nouvelle fonctionnalité
git switch -c feature/page-contact
# Travailler, commiter...
git add .
git commit -m "Ajout formulaire de contact"
# Revenir sur main
git switch main
💡 Astuce : git switch (Git 2.23+) est plus clair que git checkout car il ne fait qu’une seule chose : changer de branche. Préférez git switch pour changer de branche et git restore pour restaurer des fichiers.
Dépôts distants (push, pull, fetch) 🌐
Pour synchroniser votre dépôt local avec un dépôt distant (GitHub, GitLab, Bitbucket…).
| Commande | Description |
|---|---|
| git remote -v | Affiche les dépôts distants configurés |
| git remote add origin URL | Ajoute un dépôt distant nommé « origin » |
| git remote remove origin | Supprime un dépôt distant |
| git push origin main | Envoie vos commits vers la branche main du distant |
| git push -u origin main | Idem + lie la branche locale au distant (1ère fois) |
| git push –force | Force le push (écrase l’historique distant ⚠️) |
| git pull | Récupère les changements distants ET les fusionne |
| git pull –rebase | Récupère ET rebase au lieu de merger (historique linéaire) |
| git fetch | Récupère les changements distants SANS fusionner |
| git fetch –all | Récupère depuis tous les dépôts distants |
Exemple concret :
# Premier push d'un nouveau projet vers GitHub
git remote add origin https://github.com/user/projet.git
git push -u origin main
# Workflow quotidien
git pull # récupérer les derniers changements
# ... travailler, commiter ...
git push # envoyer ses commits
⚠️ DANGER : git push --force écrase l’historique distant. Utilisez git push --force-with-lease à la place — il refuse le push si quelqu’un d’autre a poussé entre-temps.
Historique et inspection 🔎
Pour explorer l’historique des commits, voir les différences et comprendre qui a modifié quoi.
| Commande | Description |
|---|---|
| git log | Affiche l’historique complet des commits |
| git log –oneline | Historique compact (1 ligne par commit) |
| git log –oneline –graph | Historique avec graphe des branches (visuel) |
| git log –author= »Nom » | Filtre les commits par auteur |
| git log -n 5 | Affiche les 5 derniers commits |
| git log — fichier.txt | Historique d’un fichier précis |
| git diff | Différences entre le répertoire de travail et le staging |
| git diff –staged | Différences entre le staging et le dernier commit |
| git diff main..feature | Différences entre deux branches |
| git show abc1234 | Détails d’un commit spécifique |
| git blame fichier.txt | Qui a modifié chaque ligne (auteur + date) |
💡 Astuce : Créez un alias pour le log graphique : git config --global alias.lg "log --oneline --graph --all --decorate". Ensuite, tapez simplement git lg pour un historique visuel lisible.
Annuler et corriger 🔙
Git offre plusieurs niveaux d’annulation selon que vos changements sont dans le répertoire de travail, en staging, commités localement ou pushés.
| Commande | Description |
|---|---|
| git restore fichier.txt | Annule les modifications d’un fichier (non stagé) |
| git restore –staged fichier.txt | Retire un fichier du staging (garde les modifs) |
| git reset HEAD~1 | Annule le dernier commit, garde les modifications (mixed) |
| git reset –soft HEAD~1 | Annule le dernier commit, garde le staging |
| git reset –hard HEAD~1 | Annule le dernier commit ET supprime les modifications ⚠️ |
| git revert abc1234 | Crée un nouveau commit qui annule un commit précis |
| git stash | Met de côté temporairement vos modifications en cours |
| git stash pop | Récupère les modifications mises de côté |
| git stash list | Liste tous les stashs |
| git stash drop | Supprime le dernier stash |
| git clean -fd | Supprime les fichiers non suivis et dossiers vides ⚠️ |
Quel outil utiliser pour annuler ?
| Situation | Commande recommandée |
|---|---|
J’ai modifié un fichier mais je n’ai pas encore fait git add |
git restore fichier.txt |
J’ai fait git add mais pas encore commit |
git restore --staged fichier.txt |
| J’ai commité mais pas encore pushé | git reset HEAD~1 |
| J’ai commité ET pushé | git revert abc1234 |
| Je veux mettre mon travail de côté temporairement | git stash puis git stash pop |
⚠️ Attention : git reset --hard supprime les modifications de manière irréversible. Préférez git reset (sans –hard) qui conserve vos fichiers.
Fusionner et rebaser 🔗
Deux stratégies pour intégrer le travail d’une branche dans une autre.
| Commande | Description |
|---|---|
| git merge nom-branche | Fusionne une branche dans la branche courante |
| git merge –no-ff nom-branche | Force un commit de merge (même si fast-forward possible) |
| git merge –abort | Annule une fusion en cours de conflit |
| git rebase main | Rebase la branche courante sur main |
| git rebase -i HEAD~3 | Rebase interactif (réorganiser, squash, éditer les 3 derniers commits) |
| git rebase –abort | Annule un rebase en cours |
Merge vs Rebase :
| Critère | git merge | git rebase |
|---|---|---|
| Historique | Conserve l’arborescence complète | Crée un historique linéaire |
| Commit supplémentaire | Oui (commit de merge) | Non |
| Sécurité | Ne réécrit pas l’historique | Réécrit l’historique ⚠️ |
| Quand l’utiliser | Branches partagées (main, develop) | Branches personnelles avant merge |
⚠️ Règle d’or du rebase : ne rebasez JAMAIS une branche que d’autres personnes utilisent. Le rebase réécrit l’historique — si quelqu’un d’autre travaille sur la même branche, il aura des conflits impossibles à résoudre proprement.
Tags et versions 🏷️
Les tags marquent des points spécifiques de l’historique, typiquement pour les versions (v1.0, v2.3, etc.).
| Commande | Description |
|---|---|
| git tag | Liste tous les tags |
| git tag v1.0 | Crée un tag léger sur le commit actuel |
| git tag -a v1.0 -m « Version 1.0 » | Crée un tag annoté (avec message, auteur, date) |
| git tag -a v1.0 abc1234 | Tag un commit spécifique |
| git push origin v1.0 | Pousse un tag vers le distant |
| git push origin –tags | Pousse tous les tags vers le distant |
| git tag -d v1.0 | Supprime un tag local |
| git push origin –delete v1.0 | Supprime un tag distant |
💡 Astuce : Utilisez toujours des tags annotés (-a) pour les versions de production. Les tags légers (sans -a) sont utiles comme signets temporaires mais ne contiennent pas de métadonnées.
Commandes avancées 🧙
Des commandes puissantes pour des cas d’usage spécifiques.
| Commande | Description |
|---|---|
| git cherry-pick abc1234 | Applique un commit spécifique sur la branche courante |
| git bisect start | Lance une recherche binaire pour trouver un bug |
| git reflog | Historique de TOUTES les actions (même les reset) |
| git shortlog -sn | Classement des contributeurs par nombre de commits |
| git submodule add URL | Ajoute un sous-module (dépôt imbriqué) |
| git archive –format=zip HEAD -o projet.zip | Crée une archive zip du projet |
💡 Astuce : git reflog est votre filet de sécurité ultime. Même après un git reset --hard, vous pouvez retrouver vos commits perdus dans le reflog pendant 30 jours.
Le workflow Git en 5 étapes 🔄
Voici le cycle de travail quotidien avec Git, résumé en 5 étapes :
| Étape | Commande | Ce qui se passe |
|---|---|---|
| 1. Récupérer | git pull |
Synchroniser avec le dépôt distant |
| 2. Modifier | (éditer vos fichiers) | Travailler sur votre code |
| 3. Stager | git add . |
Préparer les fichiers pour le commit |
| 4. Commiter | git commit -m "message" |
Enregistrer un snapshot dans l’historique |
| 5. Pousser | git push |
Envoyer vos commits sur le dépôt distant |
Pour les projets en équipe, ajoutez les branches :
# 1. Créer une branche pour sa tâche
git switch -c feature/ma-fonctionnalite
# 2. Travailler, add, commit (autant de fois que nécessaire)
git add .
git commit -m "Ajout du formulaire"
# 3. Mettre à jour par rapport à main
git pull origin main --rebase
# 4. Pousser sa branche
git push -u origin feature/ma-fonctionnalite
# 5. Créer une Pull Request sur GitHub/GitLab → review → merge
.gitignore : les fichiers à ignorer 🚫
Le fichier .gitignore à la racine de votre projet indique à Git quels fichiers ne pas suivre. Voici un modèle universel :
# Dépendances
node_modules/
vendor/
__pycache__/
venv/
# Build et compilation
dist/
build/
*.o
*.pyc
# Fichiers d'environnement (contiennent des secrets !)
.env
.env.local
# IDE et éditeurs
.vscode/
.idea/
*.swp
.DS_Store
Thumbs.db
# Logs
*.log
logs/
⚠️ Important : Le .gitignore ne fonctionne que pour les fichiers pas encore suivis par Git. Si vous avez déjà commité un fichier et que vous l’ajoutez ensuite au .gitignore, il restera suivi. Pour le retirer : git rm --cached fichier puis commitez.
Questions fréquentes sur Git 🤔
Quelle est la différence entre git fetch et git pull ?
git fetch télécharge les changements du dépôt distant mais ne les applique pas à vos fichiers — il met à jour vos références distantes (origin/main, etc.) pour que vous puissiez inspecter les changements avant de les intégrer. git pull fait un fetch suivi d’un merge automatique : il télécharge ET applique les changements à votre branche courante. En résumé : fetch = télécharger sans toucher, pull = télécharger + fusionner.
Comment résoudre un conflit de merge ?
Quand Git ne peut pas fusionner automatiquement, il marque les fichiers en conflit avec des balises <<<<<<<, ======= et >>>>>>>. Ouvrez chaque fichier en conflit, choisissez les modifications à garder, supprimez les balises, puis faites git add fichier et git commit. La plupart des éditeurs (VS Code, IntelliJ) proposent une interface visuelle pour résoudre les conflits plus facilement.
Comment annuler un commit déjà pushé ?
Utilisez git revert abc1234 (remplacez abc1234 par le hash du commit). Cette commande crée un nouveau commit qui annule les changements du commit ciblé, sans réécrire l’historique. N’utilisez PAS git reset sur des commits déjà pushés — cela crée des problèmes pour tous les collaborateurs.
Comment écrire un bon message de commit ?
Un bon message de commit suit ce format : une ligne courte (50 caractères max) décrivant le changement, puis une ligne vide, puis un corps optionnel avec les détails. Utilisez l’impératif : « Ajoute le formulaire de contact » plutôt que « Ajouté le formulaire ». Les conventions populaires (Conventional Commits) utilisent des préfixes : feat:, fix:, docs:, refactor:, test:, chore:.
Quelle est la différence entre git reset et git revert ?
git reset déplace la branche vers un commit antérieur et peut supprimer des commits de l’historique — il réécrit l’historique. git revert crée un nouveau commit qui annule les changements d’un commit précis — l’historique original est préservé. Utilisez reset pour les commits locaux (non pushés) et revert pour les commits déjà pushés.
Faut-il utiliser merge ou rebase ?
Les deux stratégies ont leurs avantages. Merge préserve l’historique complet avec l’arborescence des branches — c’est la méthode la plus sûre pour les branches partagées. Rebase réécrit l’historique pour créer une ligne droite propre — idéal pour nettoyer ses commits personnels avant de les fusionner. Règle simple : rebasez vos branches personnelles, mergez les branches partagées.
⬅️ Voir aussi : Commandes terminal Linux/Mac | Types de données Python
↩️ Revenir à toutes les fiches programmation & outils
