Démystifier Git : à quoi ça sert vraiment ?

Qui n’a jamais galéré avec des fichiers qu’on renomme à la chaîne pour ne pas écraser la précédente version ? page-accueil-final2.html, menu-def-OK-modif, copie-site-bis.zip… Et que dire des transferts FTP hasardeux, ou des sauvegardes manuelles copiées-collées sur clé USB ?

Git est né pour répondre à ces situations : garder un historique clair, revenir en arrière, tester des variantes sans tout casser, et surtout ne plus avoir peur de se tromper.

Dans ce premier article, on va comprendre ce qu’est Git, en quoi il diffère des plateformes comme GitHub, et pourquoi il peut être utile même quand on travaille seul·e. On ne va encore rien installer : on s’apprivoise. La suite viendra doucement, avec les outils, les commandes et les manipulations de base.
Le but, c’est de te montrer que Git n’est pas un truc réservé aux experts, mais bien un allié précieux pour tous les projets, du plus simple au plus complexe.

Git ≠ GitHub : bien comprendre les rôles

Beaucoup de gens confondent Git avec GitHub, comme si l’un ne pouvait aller sans l’autre. En réalité, Git est un outil, alors que GitHub est un service.
Git s’installe sur notre ordinateur : c’est lui qui garde en mémoire les différentes étapes d’un projet, comme un carnet de bord évolutif. Et il n’est pas nécessaire de devoir être connecté à internet pour l’utiliser.

GitHub, lui, est une plateforme en ligne qui peut héberger ce carnet de bord. Nous pouvons décider d’envoyer notre projet si nous souhaitons le sauvegarder à distance, ou le partager avec d’autres. Mais nous pouvons très bien continuer à travailler avec Git sans jamais toucher à GitHub.

D’ailleurs, GitHub n’est pas unique : il existe aussi GitLab, Bitbucket, ou encore des serveurs Git privés. Mais GitHub revient souvent dans les échanges parce qu’il est gratuit pour les projets publics, il est très utilisé dans l’open source, et il s’est bien intégré dans les outils d’apprentissage. Une bonne image pour s’y retrouver ? Git, c’est notre disque dur ; GitHub, c’est le cloud. Nous pouvons parfaitement ranger, organiser et consulter nos fichiers localement… et choisir ensuite si nous souhaitons en faire une copie ailleurs.

Git en local : un historique complet dans ton dossier

Lorsqu’on développe un site web, il arrive souvent qu’on revienne sur certaines décisions : changer un texte, essayer une autre mise en page, corriger un lien ou réorganiser des fichiers. Ces ajustements font partie du quotidien. Mais comment garder une trace de ce que nous avons modifié, quand, et surtout pourquoi ?

C’est là que Git entre en jeu. Il nous permet de créer des versions numérotées et commentées de notre projet, que Git appelle des commits. Chaque commit correspond à un instantané que nous validons nous-mêmes, avec un message explicatif : par exemple “ajout du bloc de contact” ou “modification des couleurs du menu”. À tout moment, nous pouvons consulter ces versions, revenir à l’une d’elles ou comparer les différences. Ce n’est pas Git qui décide quand une version est créée : c’est nous.

Tous ces enregistrements sont stockés dans un dossier spécial, invisible à l’œil nu, nommé .git. Ce dossier suit notre projet à la trace : il contient l’historique complet de son évolution, sans que nous ayons à dupliquer quoi que ce soit. Une fois Git activé, c’est comme si un assistant suivait nos choix et nous permettait de revenir sur n’importe quel point, sans stress.

Mais le plus puissant, c’est la possibilité de tester des idées sans casser ce qui fonctionne. Dans la vraie vie, il n’est pas rare d’hésiter sur un visuel, de devoir réécrire une page complète, ou d’explorer une nouvelle section ou fonctionnalités du site sans être certain de la garder. Git permet de créer ce qu’il appelle des branches : des pistes parallèles où l’on peut expérimenter librement.

Par exemple, imaginons que nous souhaitons ajouter une fonctionnalité de recherche dans le site. Nous ne savons pas encore si elle doit s’appuyer sur un champ libre, une liste déroulante, ou une carte interactive. Plutôt que de modifier directement la version principale du projet, nous créons une branche appelée recherche. Dans cet espace isolé, nous pouvons tester plusieurs approches, créer des fichiers dédiés, ajuster l’interface ou simuler des résultats. Tout ce que nous y faisons reste indépendant : la version en ligne du site continue de fonctionner sans être affectée.
Une fois notre choix validé, nous pourrons intégrer cette branche dans le projet principal. Et si aucune des pistes explorées ne nous convainc, il suffira de supprimer la branche. Le reste du projet n’aura jamais été exposé à ces essais.

Tout cela se fait en local, sur notre ordinateur. Git ne nécessite aucune connexion internet pour fonctionner. Il agit comme un système d’archivage intelligent, capable de nous suivre pas à pas, sans jamais nous freiner.rte d’archiviste numérique embarqué, qui note fidèlement les changements que nous décidons de lui confier, et uniquement ceux-là.

Git distant : quand nous voulons partager ou sauvegarder

Tant que nous utilisons Git uniquement en local, tout reste sur notre ordinateur. Cela suffit pour travailler seul, avancer étape par étape, et structurer nos versions. Mais dans de nombreux cas, nous avons besoin d’envoyer notre projet ailleurs : pour le sauvegarder, le partager avec d’autres personnes, ou tout simplement pour y accéder depuis un autre poste de travail.

C’est là qu’interviennent les dépôts distants. Un dépôt distant est simplement une copie du projet hébergée sur un serveur, souvent via une plateforme comme GitHub, GitLab ou Bitbucket. Une fois ce lien établi, nous pouvons à tout moment envoyer nos commits vers ce dépôt (Git parle alors de push), ou récupérer les nouveautés venues d’ailleurs (à ce moment là, Git parle de pull). L’idée est simple : garder notre dossier local synchronisé avec une version distante, comme un carnet que plusieurs personnes peuvent consulter ou enrichir.

Prenons un exemple concret. Nous travaillons sur un site avec une autre personne, à distance. Chacun utilise Git de son côté, en local. Grâce à un dépôt distant partagé, nous pouvons échanger nos avancées sans rien envoyer par e-mail, sans renommer des fichiers, sans jamais écraser accidentellement le travail de l’autre.

Ce qui est intéressant, c’est que chacun dispose d’une copie complète du projet, avec son propre historique, ses propres commits, ses propres branches. Nous pouvons donc avancer en parallèle, faire nos tests, organiser notre travail comme nous le souhaitons. Mais nous partageons aussi un socle commun, le dépôt distant, qui sert de point de ralliement. Quand l’un pousse ses modifications, elles ne viennent pas écraser celles de l’autre : elles s’ajoutent à l’historique commun, et Git est capable de faire la différence entre ce qui vient de l’un ou de l’autre. Chacun peut ensuite récupérer les ajouts de l’autre au moment qui lui convient, et Git aidera à assembler les deux parcours, ou à signaler les éventuels conflits si nous avons touché aux mêmes lignes.

Même sans collaborateur, ce dépôt distant peut servir de sauvegarde de sécurité. En cas de souci matériel, d’oubli ou de déplacement, nous pourrons toujours cloner notre projet ailleurs, à l’identique. C’est un filet de sécurité simple et fiable, sans avoir à compresser des dossiers ou copier manuellement des fichiers.

Git vs FTP : deux philosophies

Avant de découvrir Git, beaucoup d’entre nous ont utilisé le FTP pour mettre à jour un site web : on se connecte à l’hébergeur, on envoie un fichier modifié par-dessus l’ancien, et le changement est visible en ligne. C’est simple… mais aussi très risqué. Une erreur de manipulation, un fichier mal nommé, un mauvais ordre d’envoi, et l’on peut perdre une version précieuse ou provoquer un bug visible.

Git adopte une approche complètement différente. Plutôt que d’envoyer des fichiers à la volée, il construit une chaîne d’événements structurés : nous décidons ce qui change, nous le validons, puis éventuellement, nous le synchronisons. Ce qui est transféré, ce n’est pas simplement un fichier, mais un ensemble de modifications accompagnées de leur contexte. Git garde trace de ce qui a changé, mais aussi de quand, pourquoi, et par qui.

Prenons un exemple simple. Nous modifions le pied de page de notre site pour y ajouter une mention légale. Avec FTP, nous devons repérer le bon fichier, éviter d’écraser une autre version, et être sûrs de ne pas nous tromper de dossier. Avec Git, nous faisons la modification localement, nous la validons dans un commit ("ajout de la mention légale"), puis nous envoyons ce commit vers le dépôt distant. Aucun fichier n’est remplacé “à la volée” : le serveur reçoit l’évolution complète du projet, intégrée proprement à l’historique.

Cette différence de logique est essentielle. FTP fonctionne fichier par fichier, sans mémoire du passé. Git fonctionne étape par étape, avec une vision complète du projet dans le temps. C’est ce qui en fait un outil bien plus robuste, même pour les petits sites.

Et pour mettre un site en ligne ? Git remplace-t-il FTP ?

Non, Git ne remplace pas directement FTP pour publier un site sur internet. Par défaut, Git ne sait ni où se trouve votre hébergement, ni comment transformer vos fichiers en pages accessibles via HTTP. Git s’occupe de gérer vos fichiers en local et de suivre leur évolution, mais pas de les déployer.

Cela dit, de nombreuses équipes utilisent Git comme point de départ d’un déploiement automatisé. Il existe des solutions où, dès qu’un commit est poussé sur une branche particulière (par exemple main ou production), un script prend le relais et met à jour automatiquement le serveur en ligne. C’est ce qu’on appelle un déploiement continu.

Concrètement, cela peut se faire avec des outils comme GitHub Actions, GitLab CI/CD, ou des services spécialisés comme Netlify, Vercel ou Capistrano. Sur un hébergement classique, il est même possible de connecter un dépôt Git directement sur le serveur distant et d’y faire un git pull pour synchroniser les fichiers — à condition de bien maîtriser les accès et les droits d’écriture.

Mais cela demande une configuration adaptée. Dans la majorité des cas, Git est utilisé en amont de la mise en ligne : pour travailler à plusieurs, valider les modifications, tester en local… puis FTP ou un script prend le relais pour transférer les fichiers vers le serveur de production.

Seul ou à plusieurs : Git s’adapte

On associe souvent Git au travail en équipe, et c’est vrai qu’il est devenu incontournable dans les projets collaboratifs. Mais Git est aussi extrêmement utile lorsque nous travaillons seul·e sur un projet, que ce soit un site, un script, un document technique ou même un livre.

En solo, Git devient un outil de réflexion et de sécurité. Chaque commit est une façon de structurer notre travail : on peut revenir en arrière, retrouver l’état d’un fichier à une date précise, ou simplement comprendre pourquoi on a pris telle ou telle décision. Cela évite les duplications de dossiers (“site-final-bis-def”, “sauvegarde-avant-modif-footer”), et cela nous aide à progresser sereinement.

En équipe, Git déploie toute sa puissance. Chaque membre peut avancer en parallèle, proposer des modifications dans des branches distinctes, faire relire son travail avant intégration, ou résoudre les conflits si deux personnes ont modifié la même chose. Cette logique d’organisation s’appuie souvent sur des pull requests ou merge requests, selon la plateforme utilisée. Ces outils permettent de discuter du code, de tester des versions, de valider les apports de chacun… sans jamais perdre de vue l’historique du projet.

Que nous soyons seul·e ou à plusieurs, Git ne nous impose aucun rythme : il nous accompagne, que nous fassions un commit toutes les heures ou une fois par semaine. C’est cette souplesse qui en fait un compagnon de travail aussi précieux dans les petits projets que dans les grandes équipes.

Conclusion — Git, un outil à découvrir sans pression

Git peut sembler technique au premier abord, mais il répond à des besoins très concrets que nous rencontrons dès que nous travaillons sur un projet évolutif. Il nous aide à garder une trace, à expérimenter sans crainte, à collaborer plus efficacement et à revenir en arrière quand c’est nécessaire.
Ce premier article avait pour but de démystifier Git, d’en montrer les usages, la logique, et les avantages — sans entrer encore dans les commandes ou les installations.
Dans le prochain article, nous passerons à la pratique. Nous verrons comment installer Git sur notre poste, comment initialiser un projet, puis faire nos premiers commits. Et pas à pas, nous apprendrons à tirer parti de cette boîte à outils… en douceur.