Présentation
Tu modifies plusieurs fichiers.
Quelque chose cesse de fonctionner.
Et arrive cette question légèrement désagréable :
qu’est-ce qui a changé depuis le moment où tout allait encore bien ?
Git existe précisément pour que cette question possède une réponse.
Un dossier classique montre l’état actuel d’un projet.
Git ajoute son histoire.
Chaque étape importante peut être enregistrée dans un commit.
Les commits forment progressivement une suite d’états que l’on peut comparer, parcourir, partager ou utiliser pour retrouver une ancienne version.
Git transforme un ensemble de fichiers en histoire navigable.
Cette idée devient encore plus puissante avec les branches.
Le projet peut explorer plusieurs directions sans écraser immédiatement sa ligne principale.
Une fonctionnalité, une correction ou une expérimentation peuvent vivre séparément jusqu’au moment où l’on décide de les réunir.
Git est également distribué.
Lorsque l’on clone un dépôt, on ne récupère pas seulement les fichiers visibles.
Une grande partie de l’historique existe aussi localement.
Commits, branches, comparaison et création de nouvelles versions peuvent donc continuer sans connexion permanente à un serveur central.
Le dépôt distant devient surtout un point d’échange.
Cette propriété explique la différence avec GitHub.
Git sait versionner.
GitHub, GitLab, Codeberg ou une autre forge peuvent héberger et organiser la collaboration autour du dépôt.
Git peut fonctionner avec eux, avec un serveur personnel ou simplement en local.
Créé initialement pour le développement du noyau Linux, Git reste gratuit et open source.
Sa puissance s’accompagne d’un modèle mental parfois déroutant.
Working tree, staging, commits, branches, remotes et réécriture de l’histoire ne correspondent pas toujours aux intuitions construites avec un simple système de fichiers.
Mais il n’est pas nécessaire de connaître toutes les commandes de Git pour comprendre ce qui le rend précieux.
Sa logique fondamentale tient dans quelques verbes :
enregistrer → comparer → isoler → réunir → partager.
Fonctionnalités
Commits : construire la mémoire du projet
Le commit enregistre un état identifiable accompagné d’un message.
Il permet ensuite de retrouver quand une modification est apparue, quels fichiers ont changé ou à quoi ressemblait le projet auparavant.
Un bon historique ne conserve donc pas seulement des fichiers.
Il conserve une partie du raisonnement du développement.
Cette différence devient particulièrement visible plusieurs mois plus tard.
Un commit clair peut expliquer pourquoi une condition étrange existe encore dans le code ou pourquoi une architecture a été modifiée.
Le contrôle de version devient alors une forme de mémoire technique.
Staging : choisir ce qui appartient au prochain commit
Git place une étape entre les fichiers modifiés et le commit.
Cette zone de staging permet de sélectionner les changements qui doivent être enregistrés ensemble.
La fonction paraît parfois inutile au début.
Elle devient précieuse lorsque plusieurs tâches ont été mélangées pendant une même session.
Une correction de bug, une documentation et une expérimentation n’ont pas nécessairement besoin de devenir le même commit.
Le staging permet de reconstruire des unités plus cohérentes.
Il transforme une session désordonnée en histoire plus lisible.
Branches : explorer plusieurs futurs
Une branche permet de poursuivre une ligne de travail séparée.
Fonctionnalité, correction ou expérience peuvent évoluer sans perturber immédiatement la branche principale.
Cette légèreté encourage l’expérimentation.
Une architecture peut être testée puis abandonnée sans détruire l’état stable du projet.
Les branches rendent donc possible une idée assez importante :
le projet peut avoir plusieurs futurs avant d’en choisir un.
Merge et rebase
Lorsque plusieurs branches divergent, leurs changements doivent parfois être réunis.
Le merge conserve explicitement la rencontre entre plusieurs lignes de travail.
Le rebase peut repositionner une série de commits sur une nouvelle base afin d’obtenir un historique plus linéaire.
Aucune approche n’est universellement supérieure.
L’important est de comprendre que Git peut représenter ou remodeler l’histoire.
Cette puissance demande davantage de prudence lorsqu’un commit a déjà été partagé.
Réécrire une branche personnelle est une chose.
Réécrire l’histoire utilisée par plusieurs collaborateurs en est une autre.
Remotes : échanger entre plusieurs dépôts
Les remotes permettent d’échanger des commits avec d’autres dépôts.
Cette mécanique n’impose aucune plateforme particulière.
GitHub, GitLab, Codeberg, Gitea ou un simple serveur SSH peuvent tous jouer ce rôle.
Le remote n’est donc pas « le vrai dépôt ».
Il constitue une autre copie avec laquelle le projet peut communiquer.
Cette architecture explique pourquoi Git continue à fonctionner hors ligne et pourquoi plusieurs serveurs peuvent coexister autour du même projet.
Explorer et comprendre l’histoire
Git permet de comparer des versions, parcourir les commits et retrouver l’origine d’une modification.
Diff, log, show ou blame répondent à différentes questions :
- qu’est-ce qui a changé ?
- quand ?
- dans quel commit ?
- pourquoi cette ligne existe-t-elle ?
Le vrai intérêt n’est pas de trouver un coupable.
Il est de retrouver l’intention derrière un changement qui a survécu plus longtemps que son explication.
Des outils plus spécialisés comme bisect peuvent également aider à identifier le moment où une régression est apparue.
Mettre temporairement le travail de côté
Des mécanismes comme stash ou worktree répondent à une réalité très ordinaire : le développement ne respecte pas toujours l’ordre prévu.
Une tâche peut être interrompue par une correction urgente.
Un projet peut avoir besoin de plusieurs branches ouvertes simultanément.
Ces outils ne sont pas nécessaires pour comprendre Git.
Ils montrent surtout que le système a été conçu pour manipuler plusieurs états de travail sans devoir copier manuellement des dossiers.
Tags, hooks et extensions du workflow
Les tags servent notamment à identifier des commits importants ou des versions.
Les hooks permettent de déclencher des scripts à différentes étapes.
Git peut également être intégré à des outils de CI, des IDE, des agents et de nombreuses automatisations.
Ces fonctions élargissent son rôle.
Elles ne changent pas son identité fondamentale :
Git conserve et fait circuler l’histoire du projet.
Cas d’usage
Expérimenter sans peur
Une branche permet de tenter une refonte importante tout en conservant un chemin stable vers l’état précédent.
Retrouver l’origine d’un bug
L’historique aide à identifier quand un comportement est apparu et quelles modifications l’accompagnaient.
Travailler seul proprement
Git reste utile même sans équipe.
Il donne une mémoire au projet et évite la multiplication de dossiers final, final2 et final_vraiment.
Collaborer
Plusieurs personnes peuvent travailler sur des branches différentes puis échanger et réunir leurs modifications.
Versionner documentation ou configuration
Git n’est pas réservé au code.
Tout ensemble de fichiers textuels dont l’évolution doit être suivie peut bénéficier de son historique.
Préparer des releases
Tags et historique permettent d’identifier clairement les états correspondant à des versions distribuées.
Travailler sur plusieurs branches simultanément
Les worktrees peuvent isoler plusieurs espaces de travail sans dupliquer entièrement le dépôt.
Conclusion
Sa vraie force n’est pas GitHub
Git est souvent découvert à travers GitHub.
Son idée la plus importante reste indépendante de toute plateforme.
Cette indépendance donne au projet une mémoire qui peut changer de serveur sans changer de système de versionnement.
Dans un monde rempli de services cloud et d’abonnements, cette séparation reste extrêmement précieuse.
Git transforme l’expérimentation
La possibilité de revenir à un état connu réduit le coût psychologique d’une modification importante.
On peut essayer davantage parce que le passé n’est plus détruit à chaque sauvegarde.
Git devient ainsi un filet de sécurité pour la création technique.
Il ne décide pas du workflow
Git fournit commits, branches et mécanismes de fusion.
Il n’impose pas une seule manière de les utiliser.
Une équipe peut préférer des branches longues, courtes, du trunk-based development ou d’autres conventions.
La technique reste la même.
L’organisation appartient au projet.
La courbe d’apprentissage vient surtout du modèle mental
Git distingue ce qui se trouve dans le répertoire de travail, ce qui est préparé pour le prochain commit, ce qui appartient déjà à l’histoire locale et ce qui existe sur un remote.
Ces états expliquent une grande partie des messages qui semblent mystérieux au début.
Les difficultés ne viennent donc pas seulement des commandes.
Elles viennent du fait que Git possède plusieurs couches de réalité en même temps.
Une fois commits, staging, branches et remotes compris, beaucoup d’opérations cessent de sembler arbitraires.
La ligne de commande n’est pas une religion.
Les interfaces graphiques rendent branches, diffs et commits beaucoup plus visibles.
Elles peuvent être meilleures pour certaines tâches.
Comprendre quelques concepts fondamentaux reste néanmoins utile lorsque quelque chose sort du workflow prévu.
Le but n’est pas de mémoriser deux cents commandes.
Il est de savoir ce que l’outil est réellement en train de modifier.
Le texte reste son terrain naturel
Git est extrêmement efficace pour comparer des fichiers textuels.
Les gros fichiers binaires, médias lourds ou assets 3D nécessitent davantage de stratégie.
Git LFS peut aider dans certains cas.
Des systèmes spécialisés peuvent être plus adaptés à des productions artistiques très lourdes.
Points d’attention
- Git n’est pas une sauvegarde complète à lui seul : un dépôt local unique peut disparaître avec son disque.
- Les fichiers non suivis ne font pas partie de l’histoire.
- Les secrets ne doivent jamais être commités, même dans un dépôt privé.
- Réécrire l’histoire partagée peut perturber les autres collaborateurs.
- Les conflits ne sont pas des erreurs de Git : ils signalent qu’une décision humaine est nécessaire.
- Les gros fichiers binaires sont mal adaptés au stockage Git classique.
- Git LFS ajoute sa propre infrastructure et doit être pensé dès le départ pour les gros assets.
- Les conventions de branches et de commits doivent rester proportionnées au projet.
- Un historique utile dépend aussi de messages de commit compréhensibles.
- Les interfaces graphiques facilitent Git sans supprimer l’intérêt de comprendre ses concepts.
- Git est open source, mais cela ne détermine pas la licence des projets versionnés avec lui.