Git : les bases indispensables

Ce que vous saurez faire

Préparer un commit cohérent, développer sur une branche et comprendre une fusion. Git doit devenir un outil de raisonnement, pas une liste de commandes à recopier.

1. L’index est une sélection, pas une sauvegarde automatique

Imaginez deux changements : corriger une faute et ajouter une fonctionnalité. Ils n’ont pas forcément leur place dans le même commit. L’index permet de choisir ce que vous allez enregistrer.

git diff
git add README.md
git diff --staged
git commit -m "Clarifier les prérequis du projet"

git diff montre les modifications suivies non préparées. git diff --staged montre la différence entre l’index et le dernier commit. Les fichiers non suivis apparaissent dans git status, pas dans le premier diff.

Si vous modifiez encore README.md après git add, ces dernières modifications ne sont pas incluses automatiquement. Relisez l’index avant chaque commit. Un message utile explique l’intention : « Corriger le calcul des remises » est plus informatif que « Modifications ».

Référence : enregistrer ses changements.

2. Une branche pour une intention

L’atelier ci-dessous se déroule dans un nouveau dossier de test, avec Git installé et votre identité Git déjà configurée. Les commandes utilisent un terminal de type Bash ou Zsh. Elles ne nécessitent aucun compte GitHub.

mkdir atelier-git-cafe
cd atelier-git-cafe
git init -b main
printf '# Mon carnet\n' > README.md
git add README.md
git commit -m "Créer le carnet"
git switch -c documentation
printf '\nUne idée chaque jour.\n' >> README.md
git add README.md
git commit -m "Présenter le rythme du carnet"
git switch main
git merge documentation
git log --oneline --graph --all

Le résultat attendu : le texte ajouté apparaît sur main. Ici, celle-ci n’a pas évolué séparément ; Git peut simplement avancer sa référence. C’est une fusion fast-forward. Deux branches n’impliquent donc pas nécessairement un commit de fusion.

3. Un conflit demande une décision humaine

Si deux branches ont changé la même zone différemment, Git peut arrêter la fusion. git status indique les fichiers concernés. Ouvrez-les, choisissez le contenu final et retirez les marqueurs de conflit. Puis testez le résultat, préparez les fichiers résolus avec git add et terminez avec git commit.

Ne gardez pas systématiquement « notre version » : chaque branche peut contenir une partie nécessaire. Une fusion sans conflit textuel peut elle aussi introduire un bug logique.

Référence : branches et fusions.

4. Corriger sans effacer l’histoire

Pour annuler l’effet d’un commit ordinaire déjà partagé, git revert crée un nouveau commit inverse. Ce n’est pas une suppression du passé. Travaillez depuis un état propre et vérifiez le commit ciblé ; l’inversion peut provoquer des conflits. L’annulation d’un commit de fusion demande une analyse supplémentaire.

Évitez de réécrire un historique partagé juste pour le rendre plus joli. Et aucun retour arrière ne rend un secret déjà exposé à nouveau confidentiel : il faut le révoquer.

Référence : git revert.

À vous de jouer

Dans le dépôt de test, ajoutez une phrase, préparez-la, puis ajoutez une seconde phrase sans refaire git add. Que contiendra le prochain commit ? Vérifiez sans rien supprimer.

Correction commentée

Le commit contiendra uniquement la première phrase. git diff --staged montre la sélection enregistrable ; git diff montre la seconde phrase encore dans le répertoire de travail. Après le commit, celle-ci reste une modification locale. Vous venez de distinguer concrètement les trois espaces de Git.