C'est quoi Git et GitHub, et à quoi ça sert ?

1. Le problème que Git résout

Ouvre le dossier où tu ranges tes documents. Tu y trouveras probablement ceci :

rapport.docx
rapport-final.docx
rapport-final-2.docx
rapport-final-2-vraiment-final.docx
rapport-final-2-vraiment-final-OK.docx

Chaque copie avait une bonne raison d'exister au moment où elle a été faite. Le résultat, lui, a trois défauts : on ne sait plus ce qui a changé entre deux versions, on ne sait pas qui a changé quoi, et on finit par garder la mauvaise.

Git règle ces trois problèmes. Au lieu de recopier le dossier entier à chaque fois, il note l'état de tes fichiers à l'instant où tu le lui demandes — et il ne stocke jamais deux fois un contenu identique. Chaque note porte un message, une date et un auteur. C'est un carnet de bord automatique.

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

C'est la confusion la plus courante, et elle est légitime : les deux noms se ressemblent.

Autrement dit : tu peux utiliser Git toute ta vie sans jamais créer de compte nulle part. Et une plateforme sans Git ne sert à rien.

2. Le dépôt

Un dépôt (en anglais repository, souvent abrégé « repo »), c'est un dossier ordinaire auquel on a ajouté un carnet de bord. Rien de plus.

Ton dossier contient toujours tes fichiers, exactement comme avant. En plus, un sous-dossier caché nommé .git stocke tout l'historique. C'est lui qui fait la différence entre « un dossier » et « un dépôt ».

mon-projet/
|-- .git/          <- l'historique (caché, on n'y touche pas)
|-- index.html     <- tes fichiers, comme d'habitude
`-- notes.txt

Pour transformer un dossier en dépôt, une seule commande, à faire une fois :

git init

Il existe aussi une autre façon de partir : copier un dépôt qui existe déjà, avec git clone. On y revient à la section 10.

Trois zones à connaître

Quand tu travailles, un fichier passe par trois états. Comprendre ces trois mots t'évitera 90 % des blocages de débutant :

1. Modifié — tu as changé le fichier, Git l'a remarqué mais n'a rien enregistré.
2. Indexé (staged) — tu as dit à Git : « celui-là, mets-le dans la prochaine photo ». C'est la salle d'attente.
3. Enregistré (committed) — l'étape est écrite dans l'historique. Elle est à l'abri.

Le mot « index » (ou « stage ») déroute souvent. Retiens l'image du photographe : avant de déclencher, tu rassembles les personnes qui doivent être sur la photo. git add, c'est faire entrer quelqu'un dans le cadre.

3. Le commit

Un commit est une étape enregistrée. Il contient trois choses :

• ce qui a changé depuis l'étape précédente ;
• un message que tu écris, pour te souvenir du pourquoi ;
• un lien vers l'étape d'avant, ce qui forme une chaîne.

C'est ce dernier point qui rend Git puissant. Chaque étape connaît celle qui la précède. En remontant la chaîne, on peut reconstituer l'état exact du projet à n'importe quel moment de son histoire.

Créer un commit

git add notes.txt        # je mets le fichier dans la salle d'attente
git commit -m "Ajoute les notes de la réunion"

Le -m sert à écrire le message directement. Sans lui, Git ouvre un éditeur de texte — utile pour un long message, déroutant quand on débute.

Écrire un message utile

Un bon message décrit ce que fait le changement, pas ce que tu as fait de ta journée. Et il tient sur une ligne.

fix(llm-deepseek-pmu): resolve the endpoint like the official route

4. Relire l'histoire, revenir en arrière

La commande que tu utiliseras tous les jours :

git log --oneline

Elle affiche la liste des étapes, la plus récente en haut. Chaque ligne commence par un identifiant étrange, comme bcc6798bb5 : c'est l'empreinte unique du commit. Elle est calculée à partir de son contenu, ce qui la rend impossible à falsifier sans s'en apercevoir.

$ git log --oneline
bcc6798bb5 Merge de la version amont
45978540dc Corrige l'adresse d'API du plugin
56253a0544 Retire un raccourci dangereux

Voir précisément ce qui a changé

git show 45978540dc     # le détail d'un commit précis
git diff               # ce que tu as modifié et pas encore enregistré

Ces deux commandes sont ton filet de sécurité : elles ne modifient rien, elles montrent. git diff juste avant un commit est une excellente habitude — c'est le moment où l'on repère une ligne oubliée, un mot de passe laissé dans le code, un fichier en trop.

Revenir en arrière

Deux situations très différentes, qu'on confond souvent :

5. La branche

Voici la notion qui bloque le plus de débutants, alors qu'elle est simple.

Une branche n'est pas un dossier, ni une copie du projet. C'est une étiquette collée sur un commit. Rien de plus.

Quand tu enregistres une nouvelle étape, l'étiquette avance toute seule pour pointer sur cette nouvelle étape. C'est tout le mécanisme.

étapes    :  A --- B --- C
étiquette :  master          <- pointe sur C, la dernière étape enregistrée

Tu enregistres une étape D. L'étiquette suit :

étapes    :  A --- B --- C --- D
étiquette :  master               <- a avancé : elle pointe maintenant sur D

À quoi ça sert, concrètement

À travailler sur quelque chose sans abîmer ce qui marche. Tu veux essayer une nouvelle mise en page, mais ton site est en ligne et fonctionne ? Tu crées une branche, tu bricoles dessus autant que tu veux, et si le résultat ne te plaît pas, tu jettes la branche. Le site n'a jamais bougé.

git branch essai-mise-en-page     # créer l'étiquette
git switch essai-mise-en-page     # aller dessus
# ... tu travailles, tu commits ...
git switch master                 # revenir à la version stable

git switch (ou l'ancien git checkout, qui fait la même chose) déplace ton répertoire de travail sur la branche choisie. Tes fichiers changent sous tes yeux : Git remet le contenu tel qu'il était au moment de cette étiquette.

6. HEAD : « tu es ici »

Tu as maintenant plusieurs étiquettes dans ton dépôt. Comment Git sait sur laquelle tu travailles ? Grâce à un marqueur nommé HEAD.

HEAD, c'est la flèche « vous êtes ici » des centres commerciaux. Il indique la branche sur laquelle tu te trouves, et donc l'étape à partir de laquelle tes prochains commits s'enchaîneront.

étapes    :  A --- B --- C --- D
branche 1 :  essai   <- pointe sur C
branche 2 :  master  <- pointe sur D
HEAD      :  essai   <- la branche sur laquelle tu travailles en ce moment

Pour savoir où tu es, à tout moment :

git status

C'est la commande la plus utile de Git, et celle qu'on oublie d'utiliser. Elle répond à trois questions : sur quelle branche je suis, quels fichiers j'ai modifiés, quels fichiers sont prêts à être enregistrés.

7. Les copies ailleurs

Jusqu'ici, tout se passe sur ta machine. Or un dépôt qui n'existe qu'à un seul endroit reste fragile : disque qui lâche, ordinateur volé, café renversé.

Git permet donc de déclarer des dépôts distants (en anglais remotes) : des copies de ton dépôt situées ailleurs, identifiées par une adresse et un surnom.

git remote -v

La convention veut que la copie principale s'appelle origin. C'est juste un surnom : tu peux le changer.

origin    https://github.com/exemple/projet.git      (fetch)
origin    https://github.com/exemple/projet.git      (push)
forgejo   http://mon-serveur.local/moi/projet.git    (fetch)
forgejo   http://mon-serveur.local/moi/projet.git    (push)

Pourquoi plusieurs copies plutôt qu'une

• La source : le projet d'où vient ton travail. Tu y récupères les corrections des autres.
• Ta sauvegarde : ton propre serveur ou compte. C'est là que ton travail est mis à l'abri.
• Le partage : tes collègues lisent la même copie que toi.

Un dépôt peut n'avoir aucun distant (usage personnel), un seul, ou cinq. C'est toi qui décides.

8. Envoyer et recevoir

Trois commandes, souvent confondues. Elles font pourtant trois choses différentes.

git push forgejo master      # envoie la branche « master » vers le distant « forgejo »
git fetch origin             # va voir s'il y a du nouveau côté origin
git pull origin master       # récupère et intègre

9. Le merge

Un merge (« fusion ») consiste à recoudre ensemble deux fils de travail qui ont divergé.

Tu as une branche restée stable, et une branche d'essai qui contient trois nouvelles étapes. Tu veux récupérer ces trois étapes dans la branche stable : c'est un merge.

git switch master
git merge essai-mise-en-page

Deux cas, très différents

Le conflit : ce n'est pas une erreur

Quand les deux côtés ont modifié les mêmes lignes du même fichier, Git ne peut pas deviner qui a raison. Il s'arrête et te le dit : c'est un conflit.

Beaucoup de débutants croient avoir cassé quelque chose. C'est faux : Git fait exactement son travail en refusant de choisir à ta place. Il te laisse trancher, parce que toi seul sais quelle version garder.

Dans le fichier concerné, Git insère des repères. Voici ce qu'on voit réellement à l'écran :

<<<<<<< HEAD
le texte que TU avais écrit
=======
le texte que l'AUTRE avait écrit
>>>>>>> essai-mise-en-page

La première ligne s'appelle HEAD : c'est la version de la branche où tu te trouves. La dernière porte le nom de la branche qui arrive. Entre les deux, la ligne de signes égaux sépare les deux propositions.

Tu gardes ce qui est juste, tu supprimes les trois lignes de repères, tu enregistres, puis :

git add fichier-concerne.txt
git commit --no-edit

--no-edit évite l'ouverture de l'éditeur : Git a déjà préparé un message de fusion, on le garde tel quel.

10. clone et fork

Deux façons de récupérer un projet qui existe déjà. Elles se ressemblent et n'ont pas le même usage.

git clone : copier chez soi

Prendre un dépôt existant et s'en faire une copie complète sur sa machine, historique compris.

git clone https://github.com/exemple/projet.git

Après cette commande, tu as le projet entier, toutes ses étapes passées, et le distant origin déjà configuré vers l'adresse d'origine. C'est la commande par laquelle presque tout le monde commence.

fork : copier chez soi, sur la plateforme

Un fork est une copie du projet créée sur la plateforme (GitHub, GitLab, Forgejo…), rattachée à ton compte. Elle t'appartient : tu peux y écrire autant que tu veux.

Le scénario typique : tu veux modifier un projet libre dont tu n'es pas propriétaire. Tu ne peux pas écrire chez son auteur, c'est normal. Tu crées donc un fork, tu travailles dedans, puis tu proposes tes changements au projet d'origine.

En pratique, les deux se combinent : on fork sur la plateforme, puis on clone son fork sur sa machine pour travailler.

11. Les tags

Une étiquette de branche bouge : elle avance à chaque commit. Parfois, on veut au contraire marquer un point fixe. C'est le rôle du tag.

Un tag sert à nommer une étape importante — en général une version publiée :

git tag v1.0.0
git tag -a v1.0.1 -m "Corrige le calcul de la remise"

Contrairement à une branche, un tag ne bouge jamais. C'est ce qui permet de dire « la version 1.0.0, c'est exactement ces fichiers-là, pour toujours ».

Pour consulter une version étiquetée :

git checkout v1.0.0     # regarder ce qui était livré à ce moment-là
git switch master       # revenir au travail en cours

Pourquoi les numéros de version ressemblent à 0.1.6

La convention la plus répandue se lit MAJEUR.MINEUR.CORRECTIF :

• Correctif (0.1.6) — des réparations, rien de nouveau à apprendre.
• Mineur (0.1.6) — des nouveautés, mais ton usage habituel continue de fonctionner.
• Majeur (0.1.6) — des changements qui cassent la compatibilité. Un 0 en tête signale souvent un projet encore jeune, où tout peut encore bouger.

12. Les mots que tu entendras

Tu croiseras ces termes dans des conversations ou des tutoriels. Chacun est expliqué en trois lignes — assez pour ne plus être perdu, pas assez pour les maîtriser : c'est normal, ils s'apprennent par la pratique.

13. Mémo : les commandes utiles

Douze commandes couvrent l'immense majorité de l'usage quotidien. Ce tableau est fait pour être relu, pas appris par cœur.

14. GitHub : à quoi ça sert, et quelle différence avec Git ?

Tu as maintenant les commandes. Reste la question que tout le monde se pose à ce moment-là : « et GitHub, dans tout ça ? »

GitHub est un site web qui héberge ton dépôt. Tu y envoies tes commits, et ils y restent : accessibles depuis n'importe quel ordinateur, visibles par qui tu veux.

Ce qu'on y fait, concrètement

• Sauvegarder ailleurs. Ton travail n'existe plus seulement sur ton disque.
• Montrer. Un lien suffit pour que quelqu'un voie ton projet.
• Travailler à plusieurs. Chacun envoie ses étapes, le site les rassemble.
• Proposer des corrections. C'est là que vivent les pull requests dont on parlait plus haut.

Comment on y met son travail

# une seule fois : créer un dépôt vide sur le site, puis relier ton dépôt local
git remote add origin https://github.com/ton-compte/ton-projet.git

# ensuite, chaque fois que tu veux publier
git push origin main

C'est tout. Le reste — créer un compte, cliquer sur les boutons, comprendre les menus — s'apprend sur le site lui-même en cinq minutes, parce que c'est de l'interface, pas de la technique.

Pourquoi les deux noms se confondent

Parce qu'ils ont été conçus à la même époque, que les noms se ressemblent, et que la plupart des gens entendent parler de GitHub avant de savoir que Git existe. On dit « mets-le sur GitHub » comme on dit « passe-moi du scotch » : la marque a remplacé le nom de l'objet.

Ce n'est pas grave. Ce qui compte, c'est de savoir que l'un est un outil et l'autre un endroit.

15. Questions fréquentes

Les questions que tout le monde se pose en commençant. Clique sur une question pour voir la réponse.

16. Quiz : as-tu tout suivi ?

Douze questions pour vérifier ta compréhension. Clique sur la réponse qui te semble juste : la correction s'affiche immédiatement, avec l'explication. Tu peux recommencer autant de fois que tu veux.

Ce quiz corrige immédiatement chaque réponse. Aucune donnée n'est enregistrée ni transmise : tout se passe dans ton navigateur.