Si vous avez commencé à apprendre le développement web, vous avez probablement entendu parler de Git. Peut-être que vous l'utilisez déjà un peu — git add, git commit, git push — en espérant ne pas tout casser. Ce guide est là pour vous donner enfin une vraie compréhension de ce que Git fait, et pourquoi c'est l'un des outils les plus précieux de votre carrière.
Ce que Git fait vraiment
Git est un système de contrôle de version. Concrètement, il prend des "photos" de votre code à des moments précis que vous choisissez. Ces photos, ce sont les commits. À tout moment, vous pouvez revenir à n'importe quelle photo. Vous ne pouvez plus "casser" votre code de façon permanente — le pire qu'il puisse arriver, c'est de revenir à une version précédente.
Cette seule réalisation devrait vous enlever 80% de votre anxiété vis-à-vis de Git.
Les concepts à vraiment comprendre
Le commit : une sauvegarde intelligente
Un commit n'est pas une simple sauvegarde automatique. C'est une sauvegarde intentionnelle, accompagnée d'un message qui explique ce que vous avez fait. Un bon commit répond à la question : "Qu'est-ce que ce changement accomplit ?"
# Mauvais message de commit git commit -m "modif" # Bon message de commit git commit -m "Ajoute la validation du formulaire de contact"
Avec de bons messages, votre historique Git devient un journal de bord lisible. Dans 6 mois, quand vous cherchez pourquoi vous avez changé telle fonction, vous trouverez la réponse dans vos commits.
La branche : votre bac à sable personnel
Une branche, c'est une copie indépendante de votre code sur laquelle vous pouvez travailler sans affecter le reste. La branche principale s'appelle main (ou master dans les anciens projets). C'est le code "stable", celui qui fonctionne.
Chaque fois que vous commencez une nouvelle fonctionnalité, créez une branche :
git checkout -b feature/formulaire-contact
Vous travaillez sur cette branche, vous commitez, vous testez. Quand c'est prêt, vous fusionnez (merge) dans main. Si ça part dans le mauvais sens, vous supprimez la branche et rien n'a été abîmé.
Le merge et les conflits
Fusionner deux branches, c'est demander à Git de combiner les modifications des deux. Quand les deux branches ont modifié des parties différentes du code, Git le fait automatiquement. Quand elles ont modifié la même ligne, Git ne sait pas quelle version choisir — c'est un conflit.
Les conflits font peur. Ils ne devraient pas. Git vous montre exactement les deux versions en conflit :
<<<<<<< HEAD const message = "Bonjour"; ======= const message = "Hello"; >>>>>>> feature/traduction
Vous choisissez quelle version garder (ou combinez les deux), vous supprimez les marqueurs, vous commitez. C'est tout.
Le workflow quotidien du développeur
Voici comment un développeur professionnel utilise Git au quotidien :
- Mettre à jour sa branche principale : git pull origin main
- Créer une branche pour la tâche du jour : git checkout -b fix/bug-connexion
- Travailler, coder, tester
- Committer régulièrement (pas seulement à la fin) : git add . && git commit -m "..."
- Pousser sur GitHub : git push origin fix/bug-connexion
- Ouvrir une Pull Request pour que le code soit relu avant d'être fusionné
Ce flux de travail s'appelle le Feature Branch Workflow. C'est le standard dans la quasi-totalité des équipes professionnelles.
Les commandes que vous utiliserez vraiment
Oubliez les listes de 50 commandes Git. Voici celles qui couvrent 95% du travail quotidien :
git status # Voir l'état actuel git add . # Préparer tous les fichiers modifiés git add chemin/fichier.js # Préparer un fichier spécifique git commit -m "message" # Créer un commit git push origin ma-branche # Envoyer sur GitHub git pull origin main # Récupérer les dernières modifications git checkout -b nouvelle-branche # Créer et basculer sur une branche git log --oneline # Voir l'historique de commits git diff # Voir les modifications non committées
Les erreurs courantes et comment s'en sortir
"J'ai commité sur la mauvaise branche"
git log --oneline # Récupérer le hash du dernier commit git reset HEAD~1 # Annuler le dernier commit (les fichiers restent modifiés) git checkout bonne-branche git add . && git commit -m "..."
"J'ai fait des modifications que je veux abandonner"
git checkout -- . # Annule toutes les modifications non committées
"Je veux revenir à un commit précédent temporairement"
git log --oneline # Trouver le hash du commit voulu git checkout abc1234 # Se déplacer sur ce commit (mode détaché)
GitHub n'est pas Git
Une confusion fréquente : Git et GitHub sont deux choses différentes. Git est le logiciel de contrôle de version qui tourne sur votre machine. GitHub est un service en ligne qui héberge vos dépôts Git et facilite la collaboration. Il existe des alternatives à GitHub (GitLab, Bitbucket) mais le concept est le même.
Pour aller plus loin
Une fois à l'aise avec les bases, explorez ces concepts dans cet ordre :
- git stash : mettre de côté des modifications en cours sans les committer
- git rebase : réécrire l'historique pour garder un log propre
- git bisect : trouver quel commit a introduit un bug
- Les conventions de commit (Conventional Commits) : standardiser vos messages
Git est l'un de ces outils qui semblent intimidants pendant quelques semaines, puis deviennent une seconde nature. Investir du temps pour vraiment le comprendre — pas juste mémoriser les commandes — est l'un des meilleurs retours sur investissement que vous puissiez faire au début de votre carrière.
