Git devrait être votre meilleur allié. Pourtant, beaucoup de développeurs le subissent : messages de commit bâclés, branches qui traînent des semaines, conflits redoutés comme la pluie un jour de pique-nique. Bonne nouvelle : avec Claude Code, tout cela devient une simple conversation. Et vous allez surtout découvrir la règle d’or du travail avec une IA : les petits commits fréquents sont votre assurance-vie.

Ce que vous allez apprendre

• Obtenir des commits propres et des messages conventionnels en une phrase
• Créer des branches courtes, sans friction, pour chaque fonctionnalité
• Interroger l’historique git comme une véritable base de connaissances
• Ouvrir des pull requests complètes et traiter les commentaires avec le CLI gh
• Résoudre les conflits de merge avec Claude, en gardant toujours la main

Claude parle git couramment

Commençons par une définition, pour que tout le monde parte du bon pied. Git est un logiciel de gestion de versions : il enregistre l’historique complet de votre code. Chaque enregistrement s’appelle un commit. Pensez à un point de sauvegarde dans un jeu vidéo : quoi qu’il arrive ensuite, vous pourrez toujours revenir à cet instant précis. Si certains termes vous échappent en route, gardez notre glossaire ouvert dans un coin.

La bonne nouvelle, c’est que Claude Code parle git couramment. Plus besoin de mémoriser des commandes : vous décrivez votre intention, en français, et Claude la traduit en opérations git exactes.

Faites le test. Après avoir modifié quelques fichiers, dites simplement : « committe ce qu’on vient de faire ». En coulisses, Claude consulte l’état des fichiers modifiés, lit le détail des changements, et jette même un œil aux derniers messages de commit du projet pour en imiter le style. Puis il rédige un message propre, qui décrit le quoi et le pourquoi. Fini les commits nommés « fix », « test2 » ou « ça marche enfin ».

Votre équipe suit la convention des commits conventionnels ? C’est cette norme où chaque message commence par un type : feat: pour une fonctionnalité, fix: pour une correction, docs: pour la documentation, refactor: pour une réorganisation du code. Une étiquette normalisée, en somme : n’importe qui comprend la nature du changement d’un coup d’œil. Dites-le à Claude, et il s’y plie.

💡 Astuce — Pour ne pas répéter la consigne à chaque session, tapez le préfixe dièse suivi de votre règle : « # Les messages de commit suivent la convention Conventional Commits, en français ». Claude l’enregistre dans le fichier CLAUDE.md du projet. À partir de là, chaque commit respecte la règle, automatiquement.

Passons au cas classique. Vous avez modifié cinq fichiers, mais trois seulement concernent la fonctionnalité en cours ; les deux autres corrigent un détail sans rapport. Demandez : « ne committe que les fichiers du composant Panier ». Claude n’ajoutera que ces fichiers à la zone de préparation — on l’appelle aussi l’index, c’est la table de tri où l’on pose ce qui partira dans le prochain commit. Résultat : un commit ciblé pour la fonctionnalité, puis un second commit propre pour le correctif. C’est ce qu’on appelle le stage sélectif, et c’est la marque d’un historique bien tenu.

⚠️ Piège courant — Demander « committe tout » alors que des modifications sans rapport traînent dans le projet. Vous obtenez un commit fourre-tout : impossible à relire, impossible à annuler sans tout casser. Prenez deux secondes pour demander un stage sélectif. Votre historique vous dira merci.

Un dernier réflexe pratique : pour vérifier l’état de git par vous-même, préfixez votre commande d’un point d’exclamation. Tapez « !git status » et la commande s’exécute directement dans le terminal, sans passer par Claude. Rapide, direct, et vous gardez l’œil sur ce qui se passe réellement.

Des branches sans friction

Une branche, c’est une ligne de travail parallèle. Imaginez un brouillon séparé : vous écrivez, vous raturez, vous expérimentez — le document principal, lui, reste intact. En git, cette version de référence s’appelle le plus souvent la branche main.

Avec Claude, créer une branche redevient un geste naturel. Dites : « crée une branche pour cette fonctionnalité ». Claude propose un nom explicite — quelque chose comme feature/panier-code-promo — et exécute la commande. Vous voilà dans votre bac à sable, sans avoir touché à la branche principale.

Le workflow que je vous recommande tient en trois mots : petites branches courtes. Une branche égale une seule idée. Elle vit quelques heures, quelques jours au maximum, puis elle est fusionnée et supprimée. Les bénéfices sont immédiats. Des diffs courts, donc faciles à relire. Moins de conflits, car moins de temps pour diverger de la branche principale. Et un historique qui raconte une histoire claire, fonctionnalité par fonctionnalité.

Ce workflow épouse parfaitement le rythme du travail avec une IA : une tâche, une branche, une session. Vous ouvrez Claude Code, vous créez la branche, vous travaillez, vous committez, vous ouvrez la pull request. La boucle est bouclée, et chaque expérimentation reste isolée du reste.

L’historique, votre machine à remonter le temps

L’historique git n’est pas qu’une sauvegarde : c’est la mémoire collective du projet. Chaque commit raconte qui a changé quoi, quand, et — si le message est bon — pourquoi. Claude sait interroger cette mémoire pour vous, en langage naturel.

Voici trois questions à poser telles quelles :

• « Pourquoi ce fichier a-t-il changé récemment ? »
• « Qui a introduit cette fonction et pourquoi ? »
• « Qu’est-ce qui a changé sur cette branche par rapport à main ? »

Pour y répondre, Claude s’appuie sur trois outils que vous connaissez peut-être de nom :

# Ce que Claude exécute en coulisses pour enquêter
git log --oneline -20     # les vingt derniers commits, un résumé par ligne
git blame src/panier.js   # pour chaque ligne : le dernier commit qui l'a touchée
git diff main             # tout ce qui change par rapport à la branche principale

Le journal de bord, c’est git log : la liste chronologique des commits. git blame — littéralement « blâmer » — indique, ligne par ligne, le dernier commit responsable et son auteur. Et git diff compare deux états du code. Claude croise ces trois sources et vous livre une réponse en français : « cette fonction a été ajoutée il y a trois mois pour corriger un bug d’arrondi sur les remises ; voici le commit et son message ».

Cette capacité change votre rapport au code hérité. Avant de supprimer une bizarrerie, demandez son histoire. Ce qui ressemble à une verrue est parfois une correction durement acquise, posée là après un incident bien réel. L’historique le sait ; Claude vous le raconte.

Des pull requests sans quitter le terminal

Une pull request — PR pour les intimes — c’est une demande de relecture : vous proposez vos changements, un collègue les examine, puis on les fusionne dans la branche principale. C’est le rituel central du travail en équipe sur GitHub.

Pour que Claude crée des pull requests à votre place, il lui faut un compagnon : le CLI gh, l’outil officiel de GitHub en ligne de commande. Une fois gh installé et connecté à votre compte GitHub, tout se passe dans le terminal, sans jamais ouvrir le navigateur.

Ensuite, la magie opère. Dites : « ouvre une PR ». Claude analyse l’intégralité du diff de votre branche — pas seulement le dernier commit —, en déduit un titre clair et rédige une description structurée : le contexte, la liste des changements, la façon de tester. Puis il crée la pull request via gh. Ce qui vous demandait dix minutes de rédaction soignée tient désormais en une phrase. Et la description est souvent meilleure que celle qu’on écrit soi-même à la va-vite, car elle est déduite du diff complet, sans oubli.

La relecture fonctionne aussi dans l’autre sens. Un collègue a laissé des commentaires sur votre PR ? Demandez : « lis les commentaires de la PR et propose des corrections ». Claude récupère les remarques, applique les changements demandés dans le code, et peut même vous préparer une réponse pour chaque commentaire. Vous relisez, vous ajustez le ton, vous validez. Sachez enfin que la commande /review existe pour demander à Claude de relire une pull request — pratique quand c’est vous, le relecteur.

💡 Astuce — Avant de partager la pull request, relisez toujours le titre et la description générés. Claude déduit l’intention du diff, mais vous seul connaissez le contexte d’équipe : une phrase ajoutée sur le pourquoi d’un choix évite bien des questions en relecture.

Les conflits de merge, enfin sereins

Le conflit de merge, c’est la hantise des débutants. Rappelons la situation : deux branches ont modifié les mêmes lignes du même fichier, et git, honnête, refuse de choisir à votre place. Il insère alors des marqueurs dans le fichier — ces fameuses lignes de chevrons qui encadrent les deux versions — et attend votre décision.

Avant, il fallait déchiffrer les deux versions, deviner l’intention de chacune, puis reconstruire la bonne fusion à la main, avec la peur de casser quelque chose. Avec Claude, cela devient un dialogue. Essayez : « on a un conflit sur src/config.js : lis les deux versions, explique-moi ce que chaque branche voulait faire, et propose une fusion ».

Claude lit les deux côtés du conflit, remonte au besoin l’historique de chaque branche pour comprendre le contexte, puis propose une version fusionnée qui préserve les deux intentions. Votre rôle, lui, ne change pas : vous arbitrez. Vous relisez la proposition, vous demandez des ajustements si un détail cloche, et c’est vous qui donnez le feu vert.

⚠️ Piège courant — Accepter une fusion proposée sans la relire. Un code fusionné peut parfaitement compiler… et pourtant perdre une règle métier au passage. Claude propose, vous disposez : la relecture finale vous appartient, toujours.

Les petits commits : votre Ctrl+Z géant

Voici la discipline qui change tout quand on travaille avec une IA : committer souvent, par petites étapes. Un commit dès qu’un pas est franchi et que le projet fonctionne. Pas une fois par jour ; plusieurs fois par heure, les bons jours.

Pourquoi tant d’insistance ? Parce que Claude Code peut modifier beaucoup de fichiers, très vite. Si le résultat vous plaît : parfait, vous avez gagné une heure. S’il vous déçoit : il vous faut un point de retour fiable. Chaque commit est précisément cela — un point de sauvegarde vers lequel revenir en une commande, sereinement.

D’où la règle d’or de ce module : committez avant chaque grosse demande. Avant une refactorisation, avant une migration, avant tout changement qui touche plus de deux ou trois fichiers. « Committe l’état actuel » : cinq secondes. Ensuite, lâchez les chevaux. Si l’expérience tourne mal, dites simplement « reviens à l’état du dernier commit », et vous voilà au point de départ, indemne.

C’est exactement le service que rend le Ctrl+Z, l’annulation classique de vos logiciels — mais à l’échelle du projet entier. Un Ctrl+Z géant, qui survit à la fermeture du terminal et qui couvre des dizaines de fichiers d’un coup. Les développeurs qui vivent bien avec l’IA ne sont pas ceux qui ne se trompent jamais : ce sont ceux qui peuvent annuler sans douleur.

L’astuce des seniors : faites relire votre diff

Terminons par l’habitude préférée des développeurs expérimentés. Avant de pousser votre branche, demandez à Claude de relire votre propre diff : « relis ce diff comme un relecteur exigeant : bugs, cas limites, oublis ? ».

Claude passe alors les changements au crible, avec un regard neuf : la variable renommée à un endroit mais pas à l’autre, le cas limite oublié quand la liste est vide, l’affichage de débogage resté dans le code, le test qui n’a pas suivi la modification. Vous corrigez tranquillement, en local, avant que quiconque ait vu quoi que ce soit.

Cette relecture précoce coûte deux minutes et vous épargne des allers-retours entiers de revue de code. C’est aussi un excellent professeur : à force de lire les remarques, vous anticipez les problèmes avant même de les écrire. Comme un développeur senior qui relirait chaque ligne par-dessus votre épaule — la pression en moins. Et si le fonctionnement de ces assistants vous intrigue au-delà du code, notre dossier IA prolonge le sujet.

💡 Astuce — Le diff a été écrit par Claude lui-même ? Faites-le relire quand même, dans une conversation repartie de zéro avec /clear. Un regard neuf, même artificiel, attrape des choses que la session d’origine ne voit plus.

À vous de jouer

Réalisons un mini-cycle complet : branche, modification, relecture, commit. Comptez une dizaine de minutes, dans n’importe quel projet suivi par git.

1. Ouvrez un terminal dans votre projet et lancez claude. Vérifiez l’état de départ avec « !git status » : si des modifications traînent, committez-les d’abord pour partir d’un état propre.
2. Créez une branche : « crée une branche pour tester mon workflow git ». Observez le nom que Claude propose — il doit décrire l’intention.
3. Demandez une petite modification, par exemple : « ajoute un commentaire d’en-tête qui explique le rôle du fichier principal ».
4. Faites relire le travail : « relis ce diff comme un relecteur exigeant : bugs, cas limites, oublis ? ». Lisez chaque remarque et appliquez celles qui vous convainquent.
5. Committez proprement : « committe cette modification avec un message conventionnel ». Puis vérifiez : « montre-moi le dernier commit et explique son message ».
6. Bonus, si le CLI gh est installé et connecté : « ouvre une PR » — et admirez le titre et la description générés à partir de votre diff.

En résumé

• Claude parle git couramment : décrivez votre intention en français — « committe ce qu’on vient de faire » — et il exécute les commandes exactes, avec un message propre.
• Le stage sélectif garde vos commits ciblés : « ne committe que les fichiers du composant X », et le reste attendra son propre commit.
• L’historique est une source de contexte : Claude interroge git log, git blame et git diff pour répondre à « pourquoi ce code existe-t-il ? ».
• Avec le CLI gh, « ouvre une PR » génère titre et description à partir du diff ; Claude sait aussi lire les commentaires de relecture et y répondre.
• En cas de conflit de merge, Claude lit les deux versions et propose la fusion — vous arbitrez, toujours.
• Petits commits fréquents égale Ctrl+Z géant : committez avant chaque grosse demande, et faites relire chaque diff avant de pousser.

Votre code est désormais versionné, relu et protégé à chaque étape : vous pouvez expérimenter sans peur. Au prochain module, nous allons franchir un nouveau cap dans votre maîtrise de Claude Code — croyez-moi, le meilleur reste à venir.