Git et GitHub : quelle différence ?

Vous avez sûrement déjà entendu les deux mots dans la même phrase, presque comme un seul : « mets ça sur Git-GitHub ». C'est une confusion très répandue, y compris chez des gens qui codent depuis un moment. Avant de taper la moindre commande, il vaut mieux clarifier une bonne fois pour toutes ce que chaque mot désigne, parce que tout le reste de ce parcours repose sur cette distinction.

Deux outils, pas un seul

Git est un logiciel. Vous l'installez sur votre ordinateur, comme n'importe quel programme. Une fois installé, il peut suivre l'évolution des fichiers d'un projet : chaque fois que vous lui demandez d'enregistrer un état, il garde une trace de ce qui a changé. Ce travail se fait entièrement sur votre machine. Vous pouvez couper le Wi-Fi, débrancher le câble réseau, Git continue de fonctionner normalement.

GitHub, de son côté, est un site web. C'est une entreprise (propriété de Microsoft) qui propose d'héberger des projets Git sur ses serveurs, et qui ajoute par-dessus des outils pour travailler à plusieurs : une page pour discuter d'un bug, un bouton pour proposer une modification, un historique visible dans le navigateur. GitHub ne remplace pas Git, il s'appuie dessus.

Une manière simple de retenir la différence : Git est le moteur, GitHub est l'un des garages possibles où vous pouvez stationner ce que ce moteur produit. Il existe d'ailleurs d'autres garages du même genre, comme GitLab ou Bitbucket. Git, lui, reste toujours le même logiciel en dessous.

Un petit scénario pour visualiser la différence

Imaginez que vous travaillez sur un site vitrine tout simple, avec une page d'accueil et une feuille de style. Vous modifiez le titre de la page. Avec Git installé, vous pouvez demander l'enregistrement de cette modification : Git note l'ancien contenu, le nouveau, la date, et un message que vous rédigez pour décrire le changement. Ce point d'enregistrement s'appelle un commit, et nous verrons en détail comment le créer dans quelques chapitres.

Ce commit existe déjà et il est complet, avec tout son historique, alors même que vous n'avez encore rien envoyé sur Internet. Rien n'a quitté votre ordinateur. Si vous voulez que ce travail soit aussi visible sur GitHub, pour le partager avec quelqu'un ou simplement en garder une sauvegarde en ligne, il faudra une étape supplémentaire, qu'on appelle un push. Tant que ce push n'a pas eu lieu, GitHub n'a tout simplement aucune idée que ce commit existe.

C'est exactement le genre de confusion qui piège les débutants : penser qu'un commit est automatiquement visible en ligne. Ce n'est jamais le cas. Un commit est un événement local, jusqu'à ce que vous décidiez explicitement de le partager.

Le chemin qu'une modification va suivre

Tout au long de ce parcours, vous allez revoir sans cesse le même trajet, avec des mots que nous détaillerons un par un :

• Fichiers de travail : le dossier de votre projet, tel que vous le voyez et le modifiez sur votre ordinateur.
• Zone de préparation (la « staging area ») : une sélection de ce que vous voulez inclure dans le prochain enregistrement.
• Commit local : le point d'historique créé par Git, stocké sur votre machine.
• Dépôt distant : la copie hébergée, par exemple sur GitHub, que vous mettez à jour volontairement.

Retenez surtout l'ordre : rien ne saute d'étape. Un fichier modifié ne devient pas un commit tout seul, et un commit ne part pas tout seul sur GitHub. Chaque passage demande une commande précise, que vous choisissez de taper.

Pourquoi utiliser GitHub, alors ?

Si Git suffit pour suivre un projet, pourquoi tant de monde utilise-t-il GitHub ? Pour plusieurs raisons concrètes que vous croiserez plus loin dans ce parcours : avoir une sauvegarde de votre code ailleurs que sur votre seul ordinateur, pouvoir montrer un projet à quelqu'un sans lui envoyer un fichier compressé par e-mail, ou encore travailler à plusieurs sur le même projet en évitant de s'écraser mutuellement le travail. GitHub ajoute aussi des fonctionnalités propres à la plateforme, comme les Pull Requests ou les issues, que nous verrons en fin de parcours et qui n'existent pas dans Git lui-même.

Une question pour vérifier votre compréhension

Voici une situation à vous poser mentalement : vous venez de créer trois commits sur votre ordinateur, dans un projet qui n'a encore jamais été relié à GitHub. Combien de ces commits sont visibles si quelqu'un ouvre votre dépôt GitHub à cet instant ?

La réponse est zéro. Tant qu'aucun dépôt GitHub n'a été créé et qu'aucun push n'a été effectué, GitHub n'a aucune existence dans cette histoire. Vos trois commits existent bel et bien, mais uniquement sur votre disque dur.

Ce qui vous attend dans ce parcours

Dans les prochains chapitres, vous allez installer Git, puis créer un vrai petit projet nommé mon-premier-site, avec une page HTML, une feuille de style et un fichier README. Ce projet va évoluer guide après guide : vous allez le suivre avec Git, créer des branches dessus, provoquer volontairement un petit conflit pour apprendre à le résoudre, puis, seulement à partir du treizième guide, le relier à un vrai dépôt GitHub. Vous verrez alors concrètement le moment précis où votre travail local devient visible en ligne.