Versionner son code avec Git : les réflexes qui évitent la catastrophe

Perdre des heures de travail parce qu’un fichier a été écrasé par erreur, ou ne plus savoir quelle version d’un projet est réellement en production : ces situations sont exactement ce que Git a été conçu pour éliminer. Pourtant, beaucoup de débutants n’utilisent qu’une infime partie de ce que l’outil permet.

Ce que Git change concrètement

Git est un système de contrôle de version : il enregistre l’historique complet des modifications apportées à un projet, fichier par fichier, ligne par ligne. Chaque enregistrement, appelé commit, capture un instantané du code à un moment précis, avec un message qui explique ce qui a changé. Il devient alors possible de revenir à n’importe quel état antérieur du projet, de comparer deux versions, ou de comprendre pourquoi une ligne particulière a été modifiée, parfois des mois plus tard.

Des messages de commit qui racontent une histoire

Un commit intitulé simplement « corrections » n’apporte aucune information utile dans six mois. Un bon message de commit décrit ce qui a changé et pourquoi, en une phrase courte et précise : « corrige le calcul de la TVA sur les commandes multi-devises » se comprend instantanément, contrairement à un message vague. Cette discipline, qui ne coûte que quelques secondes, transforme l’historique du projet en documentation vivante.

Les branches : travailler sans casser ce qui fonctionne

Travailler directement sur la branche principale expose à un risque permanent : la moindre erreur devient immédiatement visible pour toute l’équipe, voire pour les utilisateurs si le code est déployé automatiquement. Créer une branche dédiée pour chaque fonctionnalité ou chaque correction permet d’expérimenter librement, de tester, et de ne fusionner le résultat que lorsqu’il est validé. Cette pratique, presque universelle dans les équipes professionnelles, reste étonnamment sous-utilisée par les développeurs qui démarrent seuls.

Éviter les conflits plutôt que les subir

Un conflit survient lorsque deux modifications touchent la même portion de code de façon incompatible. Plutôt que de le redouter, il vaut mieux le prévenir : synchroniser régulièrement sa branche avec la branche principale, travailler sur des fichiers ciblés plutôt que sur un unique fichier fourre-tout, et communiquer avec le reste de l’équipe sur les zones du code en cours de modification. Quand un conflit se produit malgré tout, Git indique précisément les lignes concernées, ce qui rend la résolution largement gérable une fois le mécanisme compris.

Sauvegarder ne suffit pas, il faut structurer

Un dépôt Git hébergé à distance, sur une plateforme comme GitHub ou GitLab, joue à la fois le rôle de sauvegarde et de point de collaboration. Mais la vraie valeur de Git ne réside pas dans la simple copie des fichiers : elle réside dans la capacité à comprendre, à tout moment, qui a changé quoi, pourquoi, et comment revenir en arrière sans perdre le travail effectué depuis. C’est cette discipline, plus que l’outil lui-même, qui distingue un projet maintenable d’un projet qui devient ingérable après quelques mois.