Git : le guide pratique pour ne plus jamais avoir peur de casser son code

Tu as commencé à apprendre le développement web. Tu suis des tutos, tu codes tes premiers projets, et à un moment quelqu'un te dit : "il faut utiliser Git". Alors tu tapes git add, git commit, git push en croisant les doigts pour ne rien casser.

Toi, tu sens que Git est un outil puissant. Mais entre les commandes que tu ne comprends pas à moitié et la peur de perdre ton travail, tu restes bloqué sur le strict minimum.

Le problème n'est pas que Git soit compliqué. C'est que personne ne t'a expliqué ce qu'il fait sous le capot, avec des mots simples. Les tutos te donnent des commandes à recopier sans te dire pourquoi elles existent.

Ce guide va corriger ça. À la fin, tu sauras ce que Git fait à chaque étape, tu connaîtras le flux de travail utilisé en entreprise, et tu auras un plan d'action clair pour ne plus jamais te retrouver paralysé devant ton terminal.

Le vrai problème avec Git quand on débute

Imagine la scène. Tu bosses sur ton projet depuis trois jours. Tu veux ajouter une fonctionnalité. Tu modifies un fichier, puis un autre. Au bout d'une heure, plus rien ne marche. Tu ne sais plus ce que tu as changé. Tu ne sais pas comment revenir en arrière. Panique.

Ou alors : tu travailles en équipe. Un collègue a modifié le même fichier que toi. Tu fais un git pull et le terminal affiche "CONFLICT". Ton cerveau se fige.

Ces deux situations sont les plus courantes chez les débutants. Elles partagent la même cause : tu utilises Git sans comprendre ce qu'il fait de tes fichiers à chaque commande. Et quand on ne comprend pas un outil, on le craint.

Ce que Git fait de tes fichiers (en clair)

Git est un système de contrôle de version. En termes simples : il prend des photos de ton code à des moments que tu choisis. Ces photos s'appellent des commits.

Chaque commit est un instantané complet de ton projet à un instant T. Git les stocke tous, dans l'ordre. À tout moment, tu peux revenir à n'importe quel instantané. Ton code ne peut jamais être "cassé" de façon permanente, le pire scénario est de revenir à une version précédente.

Mais Git ne prend pas ces photos tout seul. Il fonctionne en trois zones :

Ce découpage en trois zones est ce qui rend Git flexible. Tu peux modifier dix fichiers mais n'en committer que trois. Tu choisis ce qui entre dans chaque photo.

Les concepts clés, un par un

Le commit : pas une sauvegarde, un point de contrôle

Un commit n'est pas une sauvegarde automatique comme Ctrl+S. C'est une décision. Tu décides que tel ensemble de modifications forme un tout cohérent, et tu l'accompagnes d'un message qui explique ce que ce changement accomplit.

Avec de bons messages, ton historique Git devient un journal de bord. Dans six mois, quand tu chercheras pourquoi tu as modifié telle fonction, la réponse sera dans tes commits.

La branche : ton terrain d'expérimentation

Une branche, c'est une ligne de développement indépendante. La branche principale s'appelle main (ou master dans les anciens projets). C'est le code stable, celui qui fonctionne.

Chaque fois que tu veux ajouter une fonctionnalité ou corriger un bug, tu crées une branche :

Tu travailles sur cette branche, tu commites, tu testes. Quand tout est bon, tu fusionnes dans main. Si ça part dans le mauvais sens, tu supprimes la branche. Rien n'a été abîmé.

Pense aux branches comme des brouillons. Tu ne dessines pas directement sur le tableau final, tu travailles sur une feuille séparée, et tu ne colles le résultat que quand il te plaît.

Le merge : assembler le puzzle

Fusionner (merge) deux branches, c'est demander à Git de combiner les modifications des deux. Quand les deux branches ont touché des parties différentes du code, Git s'en sort tout seul. Quand elles ont modifié la même ligne, Git ne sait pas quelle version garder. C'est un conflit.

Les conflits font peur aux débutants. Ils ne devraient pas. Git te montre exactement les deux versions :

Tu choisis quelle version garder (ou tu combines les deux), tu supprimes les marqueurs, tu commites. C'est tout. Un conflit n'est pas une erreur, c'est Git qui te demande ton avis.

Git vs GitHub : deux choses différentes

Git est le logiciel de contrôle de version qui tourne sur ta machine. GitHub est un service en ligne qui héberge tes dépôts Git et facilite la collaboration (relecture de code, gestion de projet, CI/CD). Il existe des alternatives comme GitLab ou Bitbucket, mais le principe est le même.

Quand tu fais git push, tu envoies ta copie locale vers GitHub. Quand tu fais git pull, tu récupères les modifications des autres depuis GitHub. Git fonctionne très bien sans GitHub, mais GitHub ne fonctionne pas sans Git.

Le workflow quotidien en entreprise

Voici comment un développeur professionnel utilise Git au quotidien. Ce flux s'appelle le Feature Branch Workflow. C'est le standard dans la quasi-totalité des équipes.

La Pull Request (PR) est un élément clé. Elle permet à un autre développeur de lire ton code, poser des questions, suggérer des améliorations avant que le code n'arrive sur la branche principale. C'est comme ça que les équipes maintiennent la qualité du code. Si tu veux approfondir les bonnes pratiques de travail en équipe, la formation Git et GitHub de LaPolaris couvre tout ça en détail.

Les commandes qui couvrent 95% du travail

Oublie les listes de 50 commandes. Voici celles que tu utiliseras tous les jours :

C'est tout. Mémorise ces neuf commandes et tu es opérationnel pour travailler sur n'importe quel projet professionnel.

Les pièges classiques (et comment s'en sortir)

Piège 1 : committer sur la mauvaise branche

Tu as codé pendant une heure et tu réalises que tu es resté sur main au lieu de ta branche. Pas de panique :

Piège 2 : des modifications à abandonner

Tu as fait des changements qui ne mènent nulle part et tu veux repartir du dernier commit :

Piège 3 : le git add . qui embarque tout

Un classique : tu fais git add . et tu commites des fichiers sensibles (mots de passe, clés API) ou des fichiers inutiles (node_modules, .DS_Store). La solution : créer un fichier .gitignore à la racine du projet.

Tout ce qui est listé dans .gitignore sera ignoré par Git. Crée ce fichier dès le début du projet, pas après avoir déjà poussé des fichiers sensibles.

Piège 4 : ne jamais lire le message d'erreur

Git affiche des messages d'erreur qui sont, la plupart du temps, très explicites. Ils te disent ce qui ne va pas et ce que tu dois faire. Avant de paniquer, lis le message. La réponse est souvent dedans.

Piège 5 : des commits énormes et rares

Si tu commites une seule fois par jour avec 200 lignes modifiées, tu perds tout l'intérêt de Git. Des petits commits fréquents te permettent de :

• Identifier exactement quel changement a introduit un bug
• Revenir en arrière de façon chirurgicale
• Faciliter la relecture en Pull Request

Bonne règle : un commit par tâche logique. "Ajoute le champ email au formulaire", "Corrige le calcul du total", "Met à jour le style du bouton". Chaque commit a un seul objectif.

Pour aller plus loin

Une fois à l'aise avec ces bases, explore ces concepts dans cet ordre :

• git stash : mettre de côté des modifications en cours sans les committer, pratique quand tu dois changer de branche en urgence
• git rebase : réécrire l'historique pour garder un log propre et linéaire
• git bisect : trouver automatiquement quel commit a introduit un bug
• Les hooks Git : des scripts qui se lancent automatiquement avant ou après un commit (linting, tests, formatage)
• Les conventions de commit (Conventional Commits) : un format standard pour tes messages (feat:, fix:, docs:)

Si tu veux aller encore plus loin sur la CI/CD et l'automatisation de tes workflows Git, jette un oeil à l'article sur le principe Fail Fast, qui explique pourquoi détecter les erreurs tôt (y compris via Git) change tout dans un projet.

Git est l'un de ces outils qui semblent intimidants pendant quelques semaines, puis deviennent une seconde nature. Investir du temps pour comprendre ce qu'il fait, pas juste mémoriser les commandes, est l'un des meilleurs investissements que tu puisses faire au début de ta carrière.

Questions fréquentes