Git

Présentation

Tu modifies un fichier.

Ça fonctionne.

Tu en modifies trois autres.

Ça ne fonctionne plus.

Et soudain apparaît cette question merveilleusement désagréable :

« Qu’est-ce que j’ai changé depuis le moment où tout allait encore bien ? »

Git existe précisément pour que cette question ait une réponse.

Un projet n’est plus seulement son état actuel

Un dossier classique montre ce qui existe maintenant.

Git ajoute une autre dimension : ce qui existait avant.

À chaque étape importante, on peut enregistrer un état du projet dans un commit. Ces commits forment progressivement un historique que l’on peut consulter, comparer, parcourir ou utiliser pour retrouver une ancienne version.

Le projet n’est donc plus simplement un ensemble de fichiers.

Il devient une succession d’états reliés entre eux.

C’est cette idée qui fait de Git un système de contrôle de versions.

Mais elle n’explique encore qu’une partie de son intérêt.

Créé pour un projet qui n’avait pas vraiment le droit d’être simple

Git naît en 2005 autour du développement du noyau Linux.

Après la rupture entre la communauté Linux et BitKeeper, l’outil propriétaire utilisé jusque-là pour gérer les versions du noyau, Linus Torvalds lance le développement d’un nouveau système.

Les objectifs initiaux donnent assez bien le ton :

rapidité, conception relativement simple, gestion massive de branches parallèles, fonctionnement entièrement distribué et capacité à suivre un projet aussi immense que le noyau Linux.

Git est aujourd’hui maintenu par Junio C Hamano avec les contributions de nombreux développeurs.

Le contexte historique explique beaucoup de ses choix.

Git n’a pas été conçu comme une petite fonction « historique » ajoutée à un éditeur.

Il a été pensé pour permettre à énormément de modifications différentes de circuler entre de nombreuses personnes sans exiger qu’un serveur central détienne l’unique version du projet.

Distribué veut vraiment dire distribué

C’est probablement la notion la plus importante pour comprendre Git.

Quand on clone un dépôt Git, on ne récupère pas simplement les fichiers visibles du projet.

On récupère aussi son historique.

Les commits.

Les branches accessibles.

Les objets nécessaires au dépôt.

La machine locale possède donc une véritable copie du repository.

On peut créer des commits.

Explorer l’historique.

Créer des branches.

Comparer des versions.

Revenir sur certaines modifications.

Et faire une grande partie de ce travail sans connexion Internet.

Le serveur distant intervient lorsque l’on veut échanger ces changements.

Cette distinction paraît subtile jusqu’au jour où l’on comprend qu’elle sépare Git de GitHub.

Git sait versionner ton projet. GitHub sait héberger et entourer un dépôt Git de services. Ce ne sont pas la même chose.

Git peut fonctionner avec GitHub.

Avec GitLab.

Avec Codeberg.

Avec Gitea.

Avec un serveur personnel.

Avec un autre ordinateur accessible en SSH.

Ou simplement sans aucun serveur distant.

Gratuit, open source et toujours très vivant

Git est publié sous GNU General Public License version 2.0.

Il est gratuit et open source.

Le projet continue activement d’évoluer : au moment de cette vérification, le 7 août 2026, la dernière version source stable publiée est Git 2.55.0, sortie le 29 juin 2026.

Et autour du cœur en ligne de commande s’est construit un immense écosystème.

Git est directement intégré dans de nombreux IDE et éditeurs.

Il alimente des interfaces graphiques.

Il sert de fondation à des forges logicielles.

Il s’insère dans les pipelines CI/CD.

Il est utilisé par des outils de développement, des agents IA et des systèmes d’automatisation.

Le programme central reste pourtant remarquablement discret.

Souvent, on utilise Git toute la journée sans même regarder Git directement.

Fonctionnalités

Commit : donner un nom à un moment du projet

Le commit est l’une des briques essentielles de Git.

On modifie des fichiers.

On sélectionne les changements que l’on souhaite enregistrer.

Puis on crée un commit accompagné d’un message.

Ce commit devient un point identifiable dans l’histoire du projet.

Cela permet ensuite de répondre à des questions très concrètes :

Quand cette modification est-elle apparue ?

Qui l’a introduite ?

Quels fichiers ont changé ?

À quoi ressemblait le projet avant ?

Quelle différence existe entre deux versions ?

Un bon historique Git ne conserve donc pas seulement du code.

Il conserve une partie de la mémoire du développement.

Le staging : choisir ce que l’on raconte

Git introduit entre les fichiers modifiés et le commit une zone appelée index ou staging area.

Au début, cette étape donne souvent cette impression :

« Pourquoi faut-il encore faire git add alors que Git voit très bien que le fichier a changé ? »

Parce que Git permet de choisir quelles modifications doivent appartenir au prochain commit.

Tu peux avoir corrigé un bug, modifié une documentation et commencé une expérimentation dans la même session.

Rien ne t’oblige à transformer tout cela en un seul commit nommé :

divers changements

Le staging permet de reconstruire des unités plus cohérentes.

C’est une petite friction.

Mais c’est aussi l’un des endroits où Git commence à transformer une succession de gestes désordonnés en historique lisible.

Branches : expérimenter sans écraser le chemin principal

Une branche permet de poursuivre une ligne de développement séparée.

On peut créer une branche pour :

• développer une fonctionnalité ;
• corriger un bug ;
• expérimenter une architecture ;
• préparer une release ;
• travailler sans perturber la branche principale.

Les branches Git sont légères parce qu’elles reposent essentiellement sur des références vers les commits.

Cela encourage un workflow dans lequel créer une branche n’est pas une opération exceptionnelle.

C’est un geste quotidien.

Tu peux partir de main, créer feature/export-pdf, travailler dessus, puis fusionner les changements lorsque la fonctionnalité est prête.

Le projet peut ainsi explorer plusieurs futurs avant de décider lesquels méritent de rejoindre son histoire principale.

Merge et rebase : deux manières de réunir les chemins

Deux branches ont divergé.

Il faut maintenant les réunir.

Git propose plusieurs stratégies, dont deux particulièrement connues.

Aucune n’est universellement « meilleure ».

Le merge rend souvent plus visible la manière dont plusieurs lignes de travail se sont rencontrées.

Le rebase peut produire une histoire plus propre et plus facile à lire.

Mais il réécrit les commits concernés.

Ce détail compte beaucoup lorsqu’ils ont déjà été partagés.

Git offre de la puissance.

Il demande donc parfois de savoir exactement quelle partie du passé on est en train de remodeler.

Remotes : connecter des histoires séparées

Un dépôt local peut connaître un ou plusieurs dépôts distants appelés remotes.

Le plus courant porte le nom origin.

Avec eux apparaissent quelques commandes fondamentales :

fetch récupère les nouvelles références et données distantes sans les intégrer directement au travail courant.

pull récupère puis intègre les changements selon la configuration utilisée.

push envoie les commits locaux vers un dépôt distant.

Ce mécanisme explique pourquoi Git n’a besoin d’aucune plateforme précise.

Le remote peut pointer vers différents serveurs ou services compatibles.

GitHub est un choix.

GitLab en est un autre.

Un serveur SSH maison aussi.

Le protocole de collaboration et la plateforme qui l’héberge restent deux couches distinctes.

Diff, log et blame : interroger le passé

Git possède plusieurs outils pour explorer l’historique.

git diff montre les différences entre différents états.

git log permet de parcourir les commits.

git show inspecte un objet ou un commit.

git blame indique quelles lignes d’un fichier proviennent de quels commits.

Le nom « blame » — littéralement accuser — possède une élégance sociale toute particulière.

Dans les faits, l’outil sert surtout à remonter jusqu’au contexte d’une modification.

Pourquoi cette condition bizarre existe-t-elle ?

Qui l’a ajoutée ?

Dans quel commit ?

Que cherchait-on à résoudre à ce moment-là ?

Le vrai intérêt n’est pas de trouver un coupable.

C’est de retrouver l’intention derrière une ligne qui a survécu plus longtemps que son explication.

Stash : mettre le bazar dans une boîte pour cinq minutes

Tu travailles sur une fonctionnalité.

Ce n’est pas fini.

Mais il faut changer de branche immédiatement.

git stash permet de mettre temporairement de côté l’état actuel des fichiers suivis et de retrouver un espace de travail propre.

On peut ensuite revenir à la tâche précédente et restaurer les modifications.

C’est une fonction relativement simple.

Mais elle répond à une réalité très humaine du développement :

le monde ne respecte absolument pas l’ordre dans lequel nous avions prévu de terminer les choses.

Worktree : travailler sur plusieurs branches en même temps

Les worktrees permettent d’associer plusieurs répertoires de travail au même dépôt.

On peut ainsi garder la branche principale ouverte dans un dossier et travailler simultanément sur une autre branche ailleurs.

C’est particulièrement pratique lorsqu’un développement long doit rester intact pendant qu’une correction urgente apparaît.

Cette fonction prend aussi une nouvelle importance avec les outils de développement agentiques.

Plusieurs agents peuvent travailler dans des worktrees différents plutôt que de se battre pour modifier le même espace de travail.

Une fonction Git ancienne devient soudain très moderne.

Tags, signatures, hooks et outils avancés

Git peut aller bien plus loin.

Les tags permettent notamment d’identifier certains commits importants, souvent des versions.

Les signatures peuvent aider à vérifier l’origine de certains commits ou tags.

Les hooks déclenchent des scripts à différentes étapes du workflow.

Les sous-modules permettent de référencer un autre dépôt dans un projet.

bisect peut rechercher automatiquement le commit ayant introduit une régression en procédant par recherche dichotomique.

reflog conserve des références utiles pour retrouver certaines opérations locales même après des manipulations qui semblaient irréversibles.

Git possède cette qualité étrange :

on peut l’utiliser pendant des années avec une dizaine de commandes.

Et découvrir ensuite qu’il cachait encore un sous-sol entier.

Cas d’usage

Ne plus avoir peur d’essayer

Tu veux réorganiser une partie importante d’une application.

L’idée semble bonne.

Ce qui, en programmation, est parfois précisément le moment où il faut commencer à s’inquiéter.

Créer une branche permet d’essayer.

Si l’approche fonctionne, elle pourra être intégrée.

Si elle devient un marécage architectural, la branche peut simplement être abandonnée.

Git transforme ainsi l’historique en filet de sécurité pour l’expérimentation.

On ose davantage lorsque revenir en arrière ne signifie pas reconstruire manuellement ce que l’on avait hier matin.

Retrouver quand un bug est apparu

Une fonctionnalité fonctionne dans une ancienne version.

Plus maintenant.

Entre les deux : cinquante commits.

On peut évidemment commencer à lire les cinquante.

Ou utiliser Git pour comparer l’historique et, dans certains cas, git bisect pour réduire progressivement l’intervalle jusqu’au commit fautif.

Le contrôle de versions cesse alors d’être une simple sauvegarde.

Il devient un outil d’enquête.

Travailler seul sans considérer Git comme « un truc pour les équipes »

Un projet personnel n’a peut-être aucun collaborateur.

Git reste pourtant extrêmement utile.

Historiser les changements.

Tester une idée dans une branche.

Créer des versions.

Retrouver une ancienne implémentation.

Comparer deux approches.

Synchroniser le projet entre plusieurs machines.

Publier plus tard le repository sur une forge.

Le premier collaborateur de Git, c’est souvent toi-même dans trois mois, quand tu auras complètement oublié pourquoi tu as écrit ce code étrange.

Cette personne mérite un minimum de documentation.

Collaborer sans partager le même dossier

Alice clone un dépôt.

Bob clone le même dépôt.

Chacun possède son historique local et peut créer ses propres commits.

Les changements peuvent ensuite être échangés via un dépôt distant.

Git n’exige pas que tout le monde modifie une copie centrale unique à chaque instant.

Cette architecture distribuée permet des workflows très différents : équipe centralisée autour d’un serveur, forks publics, échanges de patches, plusieurs remotes ou infrastructures entièrement privées.

Git fournit la mécanique.

La communauté ou l’entreprise décide de l’organisation.

Versionner autre chose que du code

Git est principalement associé au développement logiciel.

Mais techniquement, il suit des fichiers.

Il peut donc aussi servir pour :

documentation Markdown, fichiers de configuration, scripts, notes techniques, sites statiques, documents texte ou données structurées.

Il devient beaucoup moins agréable pour de gros fichiers binaires qui changent souvent — images lourdes, vidéos, scènes 3D, fichiers de création volumineux.

Des extensions et stratégies comme Git LFS existent pour certains de ces besoins.

Mais Git révèle ici sa nature profonde :

il excelle lorsque les modifications peuvent être comparées et représentées efficacement comme une évolution de fichiers.

Avis PANACHES

Git fait partie de ces outils dont l’interface peut sembler plus compliquée que l’idée qu’ils portent.

Et son idée est formidablement simple :

ne laisse pas l’état actuel d’un projet effacer son histoire.

Tout le reste en découle.

Les commits découpent cette histoire.

Les branches permettent de lui donner plusieurs directions.

Les merges les réunissent.

Les remotes permettent à plusieurs copies de communiquer.

Le diff montre ce qui a changé.

Le log raconte comment on est arrivé là.

Sa vraie force n’est pas GitHub

C’est probablement le point le plus important après notre fiche GitHub.

Git a aujourd’hui une relation presque fusionnelle avec les grandes forges.

On apprend souvent les deux en même temps.

On crée un compte GitHub.

On clone.

On commit.

On push.

Et les frontières deviennent floues.

Pourtant, l’une des qualités les plus puissantes de Git est précisément de ne pas appartenir à GitHub.

Ton historique existe localement.

Tu peux changer de remote.

Ajouter un deuxième serveur.

Migrer vers GitLab.

Utiliser Codeberg.

Héberger ton propre dépôt.

Travailler hors ligne.

Git conserve la couche fondamentale indépendante de la plateforme.

Dans un monde où les outils deviennent facilement des abonnements, des clouds et des comptes obligatoires, cette séparation est presque rafraîchissante.

Git ne décide pas de ton workflow

Git Flow.

GitHub Flow.

Trunk-based development.

Branches longues.

Branches courtes.

Rebase systématique.

Merge commits.

Squash merge.

Git peut participer à beaucoup de méthodes différentes.

Il fournit des primitives plutôt qu’une organisation universelle.

C’est une force.

Mais aussi une source de débats fascinants capables de transformer une réunion technique de quinze minutes en fouille archéologique de convictions personnelles.

Une courbe d’apprentissage bien réelle

Git est puissant parce que son modèle possède une vraie profondeur.

Et cette profondeur demande un effort.

Working tree.

Index.

HEAD.

Branches locales.

Branches distantes.

Remotes.

Merge.

Rebase.

Detached HEAD.

Reset.

Restore.

Reflog.

À un moment, le débutant voulait juste sauvegarder ses changements et se retrouve à examiner un graphe en se demandant à quel instant exactement il a quitté le monde réel.

Les interfaces graphiques et intégrations IDE facilitent beaucoup les opérations courantes.

Mais comprendre quelques concepts internes reste extrêmement précieux.

Pas pour réciter des commandes.

Pour savoir ce que l’outil est réellement en train de modifier.

Faut-il apprendre Git en ligne de commande ?

Pas exclusivement.

Git possède un immense écosystème d’interfaces : intégrations dans VS Code et les IDE JetBrains, GitHub Desktop, GitKraken, Sourcetree, Fork, Tower et beaucoup d’autres.

Une GUI peut rendre les branches, diffs et commits beaucoup plus visibles.

Elle peut même être meilleure pour certaines tâches.

Mais connaître au moins les commandes fondamentales reste utile :

status, add, commit, log, diff, branch, switch, merge, fetch, pull, push.

Pas parce que le terminal serait plus « vrai ».

Simplement parce que la ligne de commande expose une couche commune que presque tous les outils graphiques utilisent en dessous ou reproduisent conceptuellement.

Quand préférer autre chose ?

Git domine aujourd’hui tellement son domaine qu’une alternative doit généralement répondre à un besoin assez précis.

Mercurial conserve une philosophie de contrôle de versions distribué différente et souvent perçue comme plus cohérente dans certaines opérations.

Fossil pousse beaucoup plus loin l’idée d’un outil tout-en-un en intégrant versioning, bug tracking, wiki et interface web.

Apache Subversion conserve un modèle centralisé qui peut encore convenir à certains environnements ou workflows existants.

De nouvelles approches explorent également d’autres manières de représenter les changements et les branches.

Mais pour la majorité des projets logiciels actuels, choisir autre chose que Git est rarement une décision neutre.

Pas nécessairement parce que Git est parfait.

Parce que tout l’écosystème autour de lui est gigantesque.

Points d’attention

Git n’est pas une sauvegarde complète à lui seul

Git protège admirablement l’historique suivi par le repository.

Mais si l’unique copie du dépôt se trouve sur le SSD qui vient de mourir, son architecture distribuée ne va pas invoquer magiquement un deuxième ordinateur.

Pour bénéficier réellement de cette distribution, il faut plusieurs copies : remote distant, autre machine, serveur ou système de sauvegarde.

Un commit local est une excellente version.

Ce n’est pas encore une stratégie de sauvegarde complète.

Les fichiers non suivis ne font pas partie de l’histoire

Git ne sauvegarde pas automatiquement tout ce qui se trouve dans le dossier.

Les fichiers doivent être suivis et leurs changements commités.

Les éléments exclus par .gitignore restent volontairement en dehors du repository.

C’est utile pour les caches, builds, environnements virtuels ou secrets locaux.

Mais un fichier essentiel jamais ajouté au dépôt peut disparaître sans que Git ait la moindre idée qu’il existait.

Git se souvient très bien.

À condition qu’on lui ait demandé de regarder.

Les secrets ne doivent pas être commités

Un mot de passe ou une clé API commitée puis supprimée du fichier courant peut encore exister dans l’historique Git.

Supprimer la ligne dans le commit suivant ne suffit donc pas à faire disparaître le secret des commits précédents.

Le premier réflexe doit être d’éviter son introduction dans le dépôt : variables d’environnement, fichiers ignorés, gestionnaires de secrets.

Et lorsqu’un secret a réellement été exposé, il faut généralement commencer par le révoquer ou le renouveler.

Réécrire l’histoire ne transforme pas une clé déjà copiée en secret à nouveau.

Réécrire l’historique est puissant parce que cela réécrit réellement l’historique

Rebase interactif.

Amend.

Reset.

Filter-repo.

Force push.

Git permet de remodeler profondément une série de commits.

Sur une branche personnelle, cela peut produire un historique beaucoup plus propre.

Sur une branche déjà partagée, cela peut également transformer la journée des collègues en exercice collectif de résolution de divergence.

Règle pratique :

plus un commit est partagé, plus il faut réfléchir avant de changer son identité.

Git préfère le texte aux gros binaires

Git est extrêmement efficace avec du code et des fichiers textuels.

Il est beaucoup moins naturel avec de gros fichiers binaires fréquemment modifiés.

Une vidéo de plusieurs gigaoctets.

Un fichier Photoshop lourd.

Une scène 3D.

Un projet contenant énormément d’assets binaires.

L’historique peut alors devenir massif et les différences difficiles ou impossibles à exploiter de manière classique.

Git LFS peut déplacer certains gros fichiers hors du stockage Git traditionnel tout en conservant des pointeurs dans le dépôt.

Mais pour des productions artistiques très lourdes, d’autres systèmes de gestion d’assets ou de versions peuvent parfois être plus appropriés.

Les conflits ne sont pas des erreurs de Git

Deux branches modifient la même zone d’un fichier de manière incompatible.

Git ne peut pas toujours déterminer quelle version représente l’intention correcte.

Il signale alors un conflit.

C’est frustrant.

Mais ce n’est pas réellement un échec.

Git refuse simplement d’inventer la décision humaine.

Un bon outil de merge peut aider à visualiser les deux côtés.

Le développeur doit ensuite comprendre ce que le résultat final doit réellement dire.

Dans ce cas précis, l’automatisation connaît ses limites.

Et c’est plutôt sain.

Open source ne signifie pas sans règles autour du nom

Git est bien un logiciel libre et open source sous GPLv2.

Le projet précise cependant que le nom Git et ses logos sont couverts par une politique de marque destinée notamment à éviter les confusions.

Licence du code et droits de marque sont deux sujets distincts.

On peut étudier, modifier et redistribuer le logiciel selon les conditions de sa licence.

Cela ne donne pas automatiquement carte blanche pour présenter n’importe quel produit dérivé comme s’il s’agissait du projet Git officiel.

La ligne de commande paraît parfois hostile parce qu’elle expose toute la mécanique

Git possède des commandes qui se ressemblent.

Certaines ont évolué au fil des années.

Plusieurs chemins peuvent aboutir à des résultats proches.

Et quelques opérations deviennent dangereuses lorsqu’on les utilise sans comprendre leurs conséquences.

Les interfaces modernes réduisent une grande partie de cette friction.

Mais masquer complètement Git possède aussi un coût : quand quelque chose sort du workflow prévu, il devient difficile de comprendre ce qui s’est passé.

Le meilleur compromis n’est probablement pas de mémoriser deux cents commandes.

C’est de comprendre quelques concepts solides :

commit, index, branche, HEAD, remote, merge et historique.

Une fois ces pièces en place, Git commence à arrêter de ressembler à de la magie noire.

Enfin.

La plupart du temps.

Git ne sert pas seulement à conserver ce que tu as créé. Il conserve les chemins qui t’ont permis d’y arriver.