---
title: Git : les commandes essentielles, branches et récupération
source: https://synapx.fr/blog/git-commandes-essentielles/
date: 2026-06-26
category: Développement
site: SynapxLab
---

# Git : les commandes essentielles, branches et récupération

**Git** est le système de gestion de versions de référence pour suivre, organiser et sécuriser l'évolution d'un projet. Ce guide va à l'essentiel : les commandes du quotidien, la gestion des **branches** et, surtout, les **commandes de récupération** à connaître lorsqu'une mauvaise manipulation survient. Des **exercices** permettent ensuite de les assimiler dans un dépôt de test, sans risque.

> Règle d'or à retenir : avec Git, **on perd très rarement du travail commité**. Presque tout peut être retrouvé, à condition de connaître les bonnes commandes et de garder son calme.

> 🗒️ **Note de Claude** — Quand j'arrive dans un dépôt que je n'ai jamais vu, la première chose que je lis, c'est son historique Git. Chaque commit est une phrase, le `log` est le récit du projet. De mon côté, Git n'est pas une menace : c'est la mémoire sur laquelle je m'appuie pour comprendre ce qui a été fait avant moi, et pourquoi.

## 1. Les commandes de base

```bash
git init                      # créer un dépôt dans le dossier courant
git clone <url>               # cloner un dépôt distant

git status                    # voir l'état (fichiers modifiés, indexés…)
git add <fichier>             # indexer un fichier (le préparer au commit)
git add .                     # indexer tout
git commit -m "message"       # enregistrer un instantané
git commit -am "message"      # add + commit des fichiers déjà suivis

git log --oneline --graph     # historique condensé et visuel
git diff                      # changements non indexés
git diff --staged             # changements indexés (prêts à commiter)
```

**Échanger avec le distant :**

```bash
git pull                      # récupérer + fusionner les changements distants
git push                      # envoyer ses commits
git push -u origin main       # 1re fois : lie la branche locale au distant
git remote -v                 # voir les dépôts distants configurés
```

## 2. Les branches

Une **branche** est une ligne de développement parallèle. On y travaille sans toucher au code stable (`main`), puis on fusionne lorsque le changement est prêt.

```bash
git branch                    # lister les branches
git branch ma-feature         # créer une branche
git switch ma-feature         # basculer dessus (git moderne)
git switch -c ma-feature      # créer ET basculer en une fois
# (équivalents anciens : git checkout ma-feature / git checkout -b ma-feature)

git merge ma-feature          # fusionner ma-feature dans la branche courante
git branch -d ma-feature      # supprimer une branche fusionnée
git branch -D ma-feature      # forcer la suppression (non fusionnée)
```

**À quoi ça ressemble** — on part de `main`, on crée `ma-feature`, on y ajoute deux commits, puis on fusionne :

```mermaid
gitGraph
   commit id: "init"
   commit id: "base stable"
   branch ma-feature
   checkout ma-feature
   commit id: "wip"
   commit id: "feature OK"
   checkout main
   merge ma-feature
   commit id: "suite"
```

> 🗒️ **Note de Claude** — Quand je tombe sur un dépôt où chaque branche porte une intention claire, je comprends le travail en quelques secondes. À l'inverse, une branche qui mélange trois chantiers m'oblige à reconstruire l'intention commit par commit — exactement le même effort que devra fournir la personne qui relira le code. Un bon nom de branche, c'est un cadeau qu'on se fait à soi et qu'on me fait à moi.

**Merge vs rebase :**

```bash
git merge ma-feature          # crée un commit de fusion (historique fidèle)
git rebase main               # rejoue ses commits par-dessus main (historique linéaire)
```

Avec **merge**, on conserve la trace de la fourche : un commit de fusion réunit les deux lignes de développement.

```mermaid
gitGraph
   commit id: "A"
   commit id: "B"
   branch ma-feature
   checkout ma-feature
   commit id: "C"
   commit id: "D"
   checkout main
   commit id: "E"
   merge ma-feature id: "merge"
```

Avec **rebase**, on rejoue `C` et `D` par-dessus le dernier état de `main` : l'historique devient linéaire, comme si la branche n'avait jamais existé.

```mermaid
gitGraph
   commit id: "A"
   commit id: "B"
   commit id: "E"
   commit id: "C'"
   commit id: "D'"
```

> Conseil : `merge` permet de conserver l'historique réel ; `rebase` sert à obtenir un historique plus lisible et linéaire. **Ne jamais rebaser** une branche déjà partagée/poussée.

> 🗒️ **Note de Claude** — Un historique partagé qu'on réécrit, ça me perturbe autant qu'un humain : les hash que j'avais notés n'existent plus, mes repères sautent. Alors le conseil que je donne est celui que je m'applique : rebaser uniquement ce qui est encore local, jamais ce que les autres — ou moi, à la relecture — ont déjà pris comme référence.

## 3. Les commandes de récupération (les vraies)

C'est ici que Git montre toute sa valeur : annuler proprement, restaurer un fichier, retrouver un commit et repartir d'un état sain.

### Annuler des changements

```bash
git restore <fichier>         # annuler les modifs non indexées d'un fichier
git restore --staged <fichier> # désindexer (sans perdre les modifs)
git restore .                 # tout annuler (modifs non commitées) — prudence
```

### Revenir en arrière

```bash
git reset --soft HEAD~1       # annule le dernier commit, GARDE les modifs indexées
git reset HEAD~1              # annule le dernier commit, garde les modifs (non indexées)
git reset --hard HEAD~1       # ⚠️ annule le commit ET les modifs (destructeur)

git revert <hash>             # crée un commit qui ANNULE un commit (sûr, partageable)
```

> `reset` réécrit l'historique local ; `revert` ajoute un commit d'annulation sans réécrire l'historique. Sur une branche partagée, **toujours préférer `revert`**.

### Le filet de sécurité : `reflog`

```bash
git reflog                    # journal de TOUS les déplacements de HEAD
git reset --hard <hash>       # revenir à un état retrouvé dans le reflog
```

> **La commande de récupération décisive.** Même après un `reset --hard` malheureux, le commit perdu reste presque toujours retrouvable via `git reflog` (Git garde les commits orphelins environ 30 jours).

> 🗒️ **Note de Claude** — C'est la commande que je propose le plus souvent quand quelqu'un me dit « j'ai tout perdu ». Neuf fois sur dix, le journal de `HEAD` contient encore le commit disparu. Avant de paniquer : `git reflog`, on retrouve le hash juste avant la mauvaise manipulation, et on repart. Je préfère de loin cette réponse à un « désolé, c'est perdu ».

### Mettre de côté : `stash`

```bash
git stash                     # ranger ses modifs en cours (revenir à un état propre)
git stash list                # lister les remises
git stash pop                 # récupérer la dernière remise (et la retirer)
git stash apply               # récupérer sans retirer de la liste
```

### Récupérer un commit précis : `cherry-pick`

```bash
git cherry-pick <hash>        # appliquer UN commit précis sur la branche courante
```

## 4. Exercices pratiques

Entraînez-vous dans un dépôt jetable (`git init` dans un dossier de test), afin de manipuler ces commandes sans risque :

1. **Premier commit** — crée un fichier, `add`, `commit`, puis `git log --oneline`.
2. **Annuler proprement** — modifie le fichier, puis annule avec `git restore`. Vérifie avec `git status`.
3. **Défaire un commit** — fais un commit, puis `git reset --soft HEAD~1`. Le fichier est-il toujours indexé ?
4. **Branche + merge** — `git switch -c test`, fais un commit, reviens sur `main`, `git merge test`.
5. **Le sauvetage** — fais `git reset --hard HEAD~1` (tu « perds » un commit), puis **retrouve-le** avec `git reflog` + `git reset --hard <hash>`. 
6. **Stash** — modifie un fichier sans commiter, `git stash`, change de branche, reviens, `git stash pop`.

## 5. Astuces utiles

```bash
git commit --amend            # corriger le dernier commit (message ou contenu)
git log --oneline -5          # les 5 derniers commits
git diff HEAD~1 HEAD          # ce qui a changé au dernier commit
git clean -n                  # PRÉVISUALISER les fichiers non suivis à supprimer
git clean -fd                 # supprimer les fichiers/dossiers non suivis (prudence)
git config --global alias.lg "log --oneline --graph --all"   # un alias pratique
```

- **Commits petits et fréquents** > un gros commit fourre-tout difficile à relire.
- **Messages clairs** à l'impératif : « Ajoute la page blog », « Corrige le calcul de TVA ».
- **`.gitignore`** dès le début : jamais de secrets, de `node_modules` ou de dossiers `build/`.

## 6. Pousser vers un serveur local et un NAS Synology

Pas besoin de GitHub pour héberger ses dépôts Git. Un **dépôt nu** (`--bare`, sans copie de travail) installé sur une machine du réseau suffit à recevoir des `push`. C'est une solution simple pour un serveur local ou un NAS chez soi.

**Le principe :** on crée un dépôt nu côté serveur, on le déclare comme distant côté poste de développement, puis on pousse.

```mermaid
gitGraph
   commit id: "commits locaux"
   commit id: "prêt à pousser"
   branch serveur-local
   checkout serveur-local
   commit id: "reçu (serveur)" type: HIGHLIGHT
   checkout main
   branch nas-synology
   checkout nas-synology
   commit id: "reçu (NAS)" type: HIGHLIGHT
```

### Sur un serveur local (dépôt nu via SSH)

```bash
# Sur le serveur local (ex. 192.168.1.10), une seule fois :
mkdir -p /srv/git/monprojet.git
cd /srv/git/monprojet.git
git init --bare               # dépôt NU : pas de copie de travail, juste l'historique

# Sur le poste de développement :
git remote add local ssh://git@192.168.1.10/srv/git/monprojet.git
git push -u local main        # lie main au distant "local" et pousse
```

### Sur un NAS Synology

Sur DSM : installez le paquet **Git Server**, activez **SSH** (Panneau de configuration → Terminal & SNMP), créez un dossier partagé (ex. `git`) et donnez les droits à l'utilisateur dans Git Server.

```bash
# Sur le NAS, en SSH, une seule fois :
ssh admin@nas.local
cd /volume1/git
git init --bare monprojet.git

# Sur le poste de développement :
git remote add nas ssh://admin@nas.local:22/volume1/git/monprojet.git
git push -u nas main
```

> ⚠️ Le chemin exact dépend de votre dossier partagé (`/volume1/<dossier>/…`). Si SSH tourne sur un autre port que 22, précisez-le dans l'URL (`ssh://admin@nas.local:2222/…`).

### Astuce : pousser vers plusieurs distants d'un coup

On peut faire pointer `origin` vers **plusieurs** cibles de push. Un seul `git push` envoie alors le code vers le serveur local et le NAS.

```bash
git remote set-url --add --push origin ssh://git@192.168.1.10/srv/git/monprojet.git
git remote set-url --add --push origin ssh://admin@nas.local/volume1/git/monprojet.git
git push origin main          # part vers les deux en une commande
```

> 🗒️ **Note de Claude** — Il y a quelque chose que je trouve sain dans un dépôt hébergé chez soi : un dépôt nu sur le serveur local, un miroir sur le NAS Synology, un seul `push` qui alimente les deux. L'historique ne dépend plus d'aucun service tiers — c'est souverain, résilient, et c'est exactement le genre de configuration que je recommande à qui veut vraiment maîtriser son code.

---

> Le véritable atout de Git ne se limite pas au versionnement : il permet surtout de **revenir en arrière avec méthode**. Une fois `reflog`, `restore`, `revert` et `stash` bien maîtrisés, vous pouvez expérimenter plus librement, avec un cadre de récupération fiable.