Git — ce que c’est, principes de fonctionnement et commandes

Qu’est-ce que Git ?

Git est un système de contrôle de version distribué (VCS) qui suit les modifications des fichiers et permet à plusieurs développeurs de travailler simultanément sur le même projet. Contrairement aux systèmes centralisés, dans Git chaque développeur possède une copie complète du dépôt, y compris tout l’historique des modifications, rendant le système résistant à la perte de données et ne nécessitant pas de connexion constante à un serveur central.

L’histoire de Git a commencé en 2005, lorsque Linus Torvalds a créé un nouveau VCS après que BitKeeper ait révoqué sa licence gratuite pour les développeurs du noyau Linux. Les objectifs étaient : la vitesse, la simplicité de l’architecture, le support du développement non linéaire via le branching et une distribution complète. En 3 mois, Torvalds a écrit le noyau de Git, et en un an, le projet est devenu autogéré sous la direction de Junio Hamano.

Selon l’enquête Stack Overflow (2024), Git est utilisé par 93,9% des développeurs professionnels, ce qui en fait le système de contrôle de version dominant dans l’industrie. Le concurrent le plus proche — Subversion (SVN) — n’est utilisé que dans 5,2% des projets, principalement dans les grands environnements d’entreprise avec des processus centralisés.

Comment fonctionne Git : dépôt et commits

Dépôt Git est un répertoire où Git suit les modifications de tous les fichiers. À l’intérieur du répertoire se trouve un dossier caché .git qui stocke tous les objets du système : commits, arbres, blobs et références. Lorsqu’un développeur crée un commit, Git ne copie pas les fichiers en entier — il crée un instantané et enregistre une référence vers celui-ci.

Chaque commit contient : un hash SHA-1 unique (40 caractères), une référence au commit précédent (parent), l’auteur, la date, le message du commit et une référence à un arbre qui décrit l’état des fichiers au moment du commit. La chaîne de commits forme un graphe acyclique dirigé où chaque commit pointe vers un ou plusieurs parents.

# Initialisation du dépôt
git init my-project
cd my-project

# Création d’un commit
echo "Bonjour, Git" > README.md
git add README.md
git commit -m "Initial commit"

# Affichage de l’historique
git log --oneline --graph --all

Git utilise trois zones principales : working directory (fichiers sur le disque), staging area (index où vont les fichiers préparés) et repository (historique des commits). La commande git add déplace les modifications du répertoire de travail vers le staging, et git commit enregistre le contenu du staging dans le dépôt. Cette séparation permet au développeur d’assembler un commit significatif à partir d’un ensemble de modifications sans valider chaque édition séparément.

Commandes Git de base

Les commandes Git de base couvrent 90% des opérations quotidiennes d’un développeur. La commande git clone crée une copie locale d’un dépôt distant, git pull récupère les modifications du serveur et les fusionne avec la branche actuelle, et git push envoie les commits locaux au serveur. Ces trois commandes forment le cycle principal du flux de travail avec Git.

Pour voir l’état, on utilise git status — il montre quels fichiers sont modifiés, lesquels sont dans le staging et lesquels ne sont pas suivis. git diff affiche les modifications spécifiques dans les fichiers avant l’ajout au staging. Voici un tableau des commandes les plus fréquemment utilisées :

Pour annuler des modifications, Git propose plusieurs options. git reset déplace le pointeur de la branche vers un commit spécifié et peut réinitialiser le staging ou le répertoire de travail. git revert crée un nouveau commit qui annule les modifications du commit spécifié — c’est une façon sûre d’annuler pour les branches partagées car l’historique n’est pas réécrit.

Branches dans Git : main, feature et release

Les branches dans Git sont des pointeurs mobiles légers vers un commit spécifique. Créer une nouvelle branche ne copie pas les fichiers, mais crée simplement un nouveau pointeur, rendant le branching pratiquement instantané. La branche main (anciennement master) est la branche principale du projet qui contient le code stable prêt pour la release.

La pratique standard est d’utiliser Git Flow ou GitHub Flow. Git Flow utilise les branches : main (code de release), develop (branche d’intégration), feature/* (nouvelles fonctionnalités), release/* (préparation des releases) et hotfix/* (correctifs urgents). GitHub Flow est plus simple : seulement main et les branches feature, et toutes les modifications sont livrées via Pull Request.

# Créer et changer de branche
git branch feature-auth
git checkout feature-auth
# ou avec une seule commande :
git checkout -b feature-auth

# Liste des branches
git branch --list
git branch -a  # toutes les branches, y compris les supprimées

# Supprimer une branche
git branch -d feature-auth

Une caractéristique importante du branching Git est le cherry-pick : déplacer un commit individuel d’une branche à une autre à l’aide de la commande git cherry-pick <hash>. C’est utile lorsqu’on doit transférer une correction de bug d’une branche feature vers une release sans fusionner toute la branche. Git supporte également le rebase et le rebase interactif (git rebase -i) pour squasher, réordonner et éditer les commits.

Merge et Rebase

Merge (fusion) crée un commit de fusion spécial qui a deux parents. Ce commit enregistre le fait de la fusion de deux branches et préserve l’historique complet — on peut voir où et quand la fusion a eu lieu. Merge préserve l’historique tel qu’il a été créé, ce qui simplifie l’audit mais rend le graphe de commits plus complexe.

Rebase (rebasage) au lieu de créer un commit de fusion, déplace les commits de la branche actuelle vers le sommet de la branche cible. L’historique devient linéaire — créant l’impression que le développement était séquentiel. Cependant, rebase réécrit l’historique, changeant les hash SHA-1 des commits, ce qui le rend dangereux pour les branches partagées auxquelles d’autres développeurs ont accès.

Recommandation : utilisez merge pour les branches publiques où l’historique est visible par d’autres développeurs (feature → develop), et rebase pour le travail local lorsque vous devez appliquer des modifications récentes de main à votre branche feature avant de créer un Pull Request. La règle est simple : si un commit a déjà été poussé sur le serveur — ne le rebasez pas.

Résolution des conflits

Conflit de fusion se produit lorsque Git ne peut pas fusionner automatiquement les modifications dans un seul fichier. Git marque les sections conflictuelles dans le fichier avec des marqueurs spéciaux : <<<<<<< (nos modifications), ======= (séparateur), >>>>>>> (leurs modifications). Le développeur édite manuellement le fichier, choisit l’option souhaitée ou combine les deux, et termine la fusion par un commit.

Travail avec les dépôts distants

Dépôt distant (remote) est une copie d’un dépôt Git située sur un serveur. GitHub, GitLab et Bitbucket sont les plateformes les plus populaires pour héberger des dépôts distants. Elles fournissent une interface web pour visualiser le code, gérer les accès, faire des revues de code et s’intégrer avec les systèmes CI/CD.

Dans Git, vous pouvez configurer plusieurs dépôts distants pour un projet. Par défaut, le remote principal s’appelle origin. La commande git remote add ajoute un nouveau remote, git fetch récupère les modifications sans fusion, et git pull est un raccourci pour git fetch + git merge. Pour travailler avec du code via Pull Request, un développeur crée un fork du dépôt, le clone, travaille dans une branche feature et envoie une demande de fusion au dépôt d’origine.

# Ajouter un dépôt distant
git remote add origin https://github.com/user/repo.git

# Voir les dépôts distants
git remote -v

# Pousser une branche vers le serveur
git push -u origin feature-auth

# Récupérer les modifications d’une branche distante
git pull origin main

Les dépôts distants supportent le tagging pour marquer les versions de release. Les tags peuvent être légers (simple pointeur vers un commit) ou annotés (contiennent des métadonnées : auteur, date, message). Les tags annotés sont recommandés pour les versions de release car ils portent des informations complètes sur la version et peuvent être signés avec une clé GPG pour la vérification de la paternité.

Git Worktree pour le travail parallèle

Git Worktree permet de travailler simultanément avec plusieurs branches dans différents répertoires sans basculer entre elles. La commande git worktree add ../feature-auth feature-auth crée un nouveau répertoire de travail feature-auth où vous pouvez écrire du code sans changer de branche dans le répertoire principal. Worktree est utile pour les corrections rapides dans une branche release lorsque le répertoire principal est occupé par un développement à long terme.

Git Submodules pour les dépendances

Git Submodules est un mécanisme pour inclure un dépôt Git dans un autre. Un sous-module stocke une référence à un commit fixe d’un dépôt externe, garantissant la reproductibilité de la construction. La commande git submodule add https://github.com/example/lib.git ajoute une bibliothèque externe comme sous-module. Lors du clonage d’un projet avec des sous-modules, il faut exécuter git submodule update --init --recursive pour télécharger toutes les dépendances.