Qu'est-ce que Git et pourquoi tout développeur en a besoin

Git, c'est un système de contrôle de version

Git est un logiciel qui mémorise l'historique des modifications des fichiers d'un projet. Chaque fois que vous enregistrez l'état du code, Git sauvegarde un instantané (un commit) avec son auteur, sa date et sa description. Vous pouvez revenir à n'importe quel instantané, le comparer à l'état actuel, retrouver qui a modifié une ligne précise et pourquoi.

Si vous avez déjà conservé des dossiers « projet_v2 », « projet_final » et « projet_final_VRAIMENT_FINAL », vous faisiez déjà du contrôle de version — simplement à la main. Git fait la même chose automatiquement, de façon compacte et sans risque de perdre quoi que ce soit. C'est pourquoi, quand des développeurs parlent de Git, ils ne désignent pas seulement un programme, mais un outil de travail de base, aussi indispensable que l'éditeur de code.

En quoi Git diffère d'un « dossier de copies » et d'un stockage cloud

Un stockage cloud conserve la dernière version d'un fichier et, au mieux, quelques copies automatiques. Git conserve un historique qui a du sens : c'est vous qui décidez quand enregistrer les modifications, et vous écrivez ce qui a été fait. En outre, Git sait faire ce qu'aucun disque ne sait faire :

• mener plusieurs lignes de développement en même temps (les branches) et les fusionner ;
• afficher les différences ligne par ligne entre deux versions (git diff) ;
• combiner les modifications de plusieurs personnes dans les mêmes fichiers ;
• trouver le commit après lequel un bug est apparu (git bisect) ;
• fonctionner sans internet — tout l'historique est stocké chez vous, en local.

Que signifie Git ? Origine et sens du nom

Git n'a pas de signification officielle — ce n'est pas un acronyme. Linus Torvalds a baptisé le programme à sa manière : en argot britannique, « git » désigne un type désagréable et têtu. Torvalds plaisantait en disant qu'il nommait tous ses projets d'après lui-même. Une traduction littérale serait à peu près « sale type » ou « crétin ».

Dans le premier README du projet, l'auteur proposait plusieurs développements humoristiques du nom : par exemple « global information tracker » quand tout fonctionne, et une version injurieuse quand tout casse. Donc si l'on vous demande en entretien « que signifie le sigle Git », la bonne réponse est : rien, c'est un mot et non un acronyme.

On écrit et on prononce simplement « Git », avec un g dur, comme dans « guitare », et non « djit ».

D'où vient Git

Jusqu'en 2005, les développeurs du noyau Linux utilisaient le système propriétaire BitKeeper. Lorsque la licence gratuite accordée à la communauté a été retirée, Torvalds a écrit son propre système en quelques semaines. Le cahier des charges était exigeant : rapidité sur un projet énorme, fonctionnement entièrement distribué, protection fiable de l'historique contre la corruption et gestion confortable de milliers de branches parallèles.

Peu après, Junio Hamano a repris la maintenance du projet, et il en est toujours le mainteneur. Aujourd'hui, Git est un logiciel libre sous licence GPLv2, et c'est sur lui que reposent GitHub, GitLab, Bitbucket, Gitea et de nombreuses plateformes d'entreprise.

Comment fonctionne Git en tant que système

Pour que Git cesse de ressembler à un ensemble de commandes magiques, il est utile de comprendre trois idées. Elles expliquent presque tout le comportement du système.

1. Des instantanés, pas des différences

Beaucoup d'anciens systèmes stockaient les changements comme une suite de modifications de fichiers. Git raisonne en instantanés : chaque commit représente l'état complet du projet au moment de l'enregistrement. Pour ne pas gaspiller d'espace, les fichiers inchangés ne sont pas recopiés : le commit pointe simplement vers l'objet déjà stocké. Lors du compactage du dépôt, Git compresse en plus les objets similaires, si bien que l'historique d'un gros projet occupe peu de place.

2. Tout est adressé par un hash

Chaque objet Git — contenu d'un fichier (blob), structure d'un dossier (tree), commit (commit) — reçoit un identifiant calculé à partir de son contenu. Historiquement, il s'agit de SHA-1 (40 caractères hexadécimaux) ; les versions récentes permettent de créer un dépôt en SHA-256. Impossible de modifier un ancien commit en douce : son hash changerait, ainsi que ceux de tous les commits suivants.

$ git log --oneline -3
a3f9c21 Ajouter le formulaire de connexion
7b02e4d Corriger la validation de l'e-mail
1c8d5f0 Premier commit

Les chaînes courtes à gauche sont les hashs abrégés des commits. Ils permettent d'accéder à n'importe quelle version : git show 7b02e4d.

3. Les trois états d'un fichier

C'est la base de Git, et la question tombe dans presque tous les entretiens. Un fichier du projet peut se trouver dans l'une des trois zones :

L'index est ce qui distingue Git de nombreux autres systèmes. Il permet de ne mettre dans un commit qu'une partie des modifications : par exemple, la correction d'un bug d'un côté et le renommage de variables de l'autre. L'historique reste ainsi lisible.

Un système distribué : pourquoi chacun possède une copie complète

Git est un système de contrôle de version distribué (DVCS). Quand vous clonez un dépôt, vous récupérez non seulement les derniers fichiers, mais tout l'historique du projet. La plupart des opérations — commit, consultation de l'historique, création de branche, comparaison — s'exécutent en local, instantanément, sans serveur.

Dans ce modèle, un serveur comme GitHub n'est qu'une copie de plus du dépôt, que l'équipe a choisi de considérer comme la référence. S'il est indisponible, le travail ne s'arrête pas : vous continuez à committer et vous enverrez vos modifications plus tard avec git push. Si le serveur est carrément perdu, l'historique peut être restauré à partir de n'importe quel clone.

Git et GitHub, ce n'est pas la même chose

Une confusion fréquente chez les débutants. Git est un programme qui tourne sur votre ordinateur. GitHub est un service web qui héberge des dépôts Git et propose des outils de travail en équipe : pull requests, revue de code, tickets, CI. GitLab et Bitbucket sont des services similaires.

Vous pouvez utiliser Git sans GitHub du tout — par exemple pour des notes personnelles ou un projet local. En revanche, GitHub sans Git n'a aucun sens : il est entièrement construit autour de ses dépôts.

Les bases de Git : le cycle de travail minimal

Voici à quoi ressemble le travail au quotidien. Ces quelques commandes couvrent l'essentiel de ce qu'un développeur fait chaque jour.

# créer un dépôt dans le dossier courant
git init

# voir ce qui a changé
git status

# ajouter des fichiers à l'index
git add index.html style.css

# enregistrer un instantané
git commit -m "Intégrer la page d'accueil"

# consulter l'historique
git log --oneline

# créer une branche et basculer dessus
git switch -c feature/login

# fusionner la branche dans la branche principale
git switch main
git merge feature/login

# envoyer les modifications au serveur
git push origin main

La commande git switch est apparue avec Git 2.23 pour remplacer, de façon plus claire, une partie des usages de git checkout. Dans les anciens tutoriels, vous verrez git checkout -b feature/login — c'est exactement la même chose.

Que se passe-t-il lors d'un git commit

Git prend le contenu de l'index, enregistre chaque fichier sous forme de blob, construit des objets tree pour les dossiers et crée un objet commit. Le commit contient : une référence vers l'arbre, une référence vers le commit parent (ou deux, après un merge), l'auteur, le committer et le message. Ensuite, le pointeur de la branche courante avance sur le nouveau commit. Une branche Git, c'est littéralement un fichier contenant le hash du dernier commit — voilà pourquoi les branches se créent en quelques millisecondes.

À quoi sert Git pour un développeur : les raisons concrètes

Expérimenter sans crainte

Toute modification est réversible. Vous avez cassé le code ? git restore fichier rétablit la dernière version enregistrée. Un mauvais commit est déjà dans l'historique ? git revert crée un commit inverse sans réécrire l'historique partagé. Cela change votre façon de travailler : vous osez davantage, car revenir en arrière ne coûte que quelques secondes.

Travailler en équipe sans chaos

Chaque développeur travaille dans sa propre branche sans gêner les autres. Quand une tâche est terminée, les modifications passent en revue de code puis sont fusionnées dans la branche principale. Si deux personnes ont modifié la même portion de code, Git signale un conflit et vous laisse le résoudre en connaissance de cause, au lieu d'écraser silencieusement le travail de quelqu'un.

L'historique comme documentation

De bons messages de commit répondent à la question « pourquoi le code est-il ainsi ». La commande git blame fichier indique qui a modifié chaque ligne en dernier et dans quel commit, et git log -p fichier retrace toute l'évolution du fichier. Un an plus tard, cela économise des heures d'enquête.

Une exigence des recruteurs

La maîtrise de Git figure dans pratiquement toutes les offres d'emploi de développeur, testeur, ingénieur DevOps ou data analyst. En entretien, on ne vérifie pas des commandes apprises par cœur, mais votre compréhension : quelle différence entre merge et rebase, qu'est-ce que l'index, comment annuler un commit, comment résoudre un conflit. Et un profil GitHub avec un historique de commits soigné fait office de portfolio.

Qui d'autre a besoin de Git

Git est utile partout où il y a des fichiers texte et où l'historique compte : rédacteurs techniques (documentation en Markdown), intégrateurs web, analystes (scripts SQL, notebooks), administrateurs système (configurations de serveurs, infrastructure as code). Pour les gros fichiers binaires — vidéos, PSD, jeux de données — on utilise l'extension Git LFS, car Git lui-même est optimisé pour le texte.

Pro Git, le meilleur livre sur Git

Pour aller plus loin, commencez par le livre « Pro Git » de Scott Chacon et Ben Straub. Il est gratuit, distribué sous licence libre et publié sur le site officiel git-scm.com dans la rubrique Book, y compris en traduction française. C'est ce fameux « pro git » que beaucoup recherchent : un véritable manuel, des bases jusqu'au fonctionnement interne.

Pour le lire avec profit :

• chapitres 1 à 3 (introduction, bases, branches) — le minimum indispensable, reproduisez les commandes dans le terminal ;
• le chapitre sur les dépôts distants et GitHub — quand vous commencerez à travailler en équipe ;
• le chapitre « Les tripes de Git » — quand vous voudrez vraiment comprendre comment fonctionnent les objets et les références.

Le second appui officiel est l'aide intégrée : git help commit ou git commit --help ouvrent la documentation complète de la commande, et git commit -h affiche un résumé des options.

Les idées reçues des débutants

• « Git enregistre les fichiers automatiquement. » Non : tant que vous n'avez pas fait de commit, les modifications n'existent que dans le répertoire de travail.
• « Le commit part directement sur GitHub. » Le commit est local. Il n'arrive sur le serveur qu'après git push.
• « git add ne sert qu'aux nouveaux fichiers. » git add ajoute aussi à l'index les modifications des fichiers déjà suivis.
• « Ce qui a été supprimé de l'historique est perdu. » Presque toujours récupérable : git reflog garde la trace des déplacements de pointeurs, et un commit « perdu » se retrouve grâce à son hash.
• « Les branches sont des copies du projet. » Une branche est un pointeur léger vers un commit, pas un doublon des fichiers.

Par où commencer pour apprendre Git

1. Installez Git et vérifiez la version : git --version.
2. Configurez votre nom et votre e-mail : git config --global user.name et user.email.
3. Créez un dépôt d'entraînement, faites 5 à 10 commits, regardez git log et git diff.
4. Manipulez les branches : créez-en, fusionnez-les, provoquez volontairement un conflit et résolvez-le.
5. Créez un compte GitHub, poussez-y votre dépôt et ouvrez votre première pull request.

Cet ordre donne des résultats plus vite que la lecture linéaire de manuels de référence : vous voyez immédiatement comment chaque commande modifie l'état du dépôt.

En résumé

Git est un système de contrôle de version distribué qui stocke l'historique du projet sous forme d'instantanés, le protège par des hashs et permet à une équipe de travailler en parallèle dans des branches. Son nom n'a pas de signification cachée, et en pratique Git est l'outil indispensable de tout développeur. Maîtrisez le cycle add — commit — push, comprenez les trois zones des fichiers et les branches, puis approfondissez avec le livre Pro Git. Tout cela est traité pas à pas, du premier commit à la pull request, dans les travaux pratiques du cours Git.