Prise en main de Git — Chapitre 1 / 4
Comprendre le modèle Git
Avant de taper des commandes, il faut comprendre comment Git fonctionne. Dans ce chapitre, on va comparer Git à un cahier de photographe. Après cette lecture, Git ne sera plus une boîte noire pour toi.
L'analogie : le cahier de photographe
Tout au long de ce chapitre, on va comparer Git à un cahier de photographe. Voici les correspondances :
Ton appareil photo
= Working directory (ton dossier de travail)
Le plateau de sélection
= Staging area (les fichiers prêts à être sauvegardés)
Le cahier
= Repository (l'historique de tes sauvegardes)
Une page du cahier
= Un commit (un snapshot complet de tes fichiers)
Un marque-page
= Une branche (un pointeur vers une page)
La page ouverte
= HEAD (la page que tu lis en ce moment)
Pourquoi Git existe
Git a été créé en 2005 par Linus Torvalds. Linus Torvalds est aussi le créateur de Linux.
Il avait besoin d'un outil pour gérer du code. Un outil qui fonctionne même quand des milliers de personnes travaillent en même temps. Un outil qui fonctionne sans serveur central.
Avant Git, les développeurs utilisaient des outils comme SVN ou CVS. Ces outils avaient besoin d'un serveur central. Si le serveur tombait en panne, personne ne pouvait travailler.
Mot clé : distribué
Git est distribué. Cela veut dire que chaque personne a une copie complète du projet sur sa machine. C'est comme si chaque photographe avait son propre cahier complet. Pas besoin de connexion internet pour travailler.
Point important
Git n'est pas GitHub. Git est l'outil qui gère les versions de ton code. GitHub est un site web qui héberge des projets Git. Tu peux utiliser Git sans jamais aller sur GitHub.Comprendre la différence Git vs GitHub →
Snapshot : la vraie nature de Git
Mot clé : snapshot
Un snapshot est une photo complète de tous tes fichiers à un moment précis. Dans notre cahier de photographe, chaque page est un snapshot. La page montre toutes les photos du projet, pas seulement les nouvelles.
Beaucoup de systèmes stockent les différences entre les fichiers. Git fonctionne autrement : il prend une photo complète à chaque commit.
Autres systèmes (SVN)
Pour voir la version actuelle, il faut rejouer toutes les modifications depuis le début.
Git
Commit 1
index.html → "Hello"
Commit 2
index.html → "Bonjour"
style.css → "body { margin: 0 }"
Commit 3
index.html → "Bienvenue"
style.css → "body { margin: 0 }"
footer.html → "Pied de page"
Chaque commit contient tous les fichiers. Accès direct à n'importe quelle version.
Si un fichier n'a pas changé, Git ne le recopie pas. Il garde juste un lien vers la version précédente. C'est rapide et ça ne prend pas beaucoup de place.
Les 3 zones de travail
Git organise ton travail en 3 zones. Comprendre ces 3 zones est essentiel pour comprendre le modèle Git.
📷
Working Directory
Ton dossier de travail
Tu modifies tes fichiers ici
🗂️
Staging Area
Zone de préparation
Tu choisis quoi sauvegarder
📖
Repository
L'historique
Tes sauvegardes permanentes
C'est comme notre cahier de photographe : tu prends des photos (working directory), tu choisis lesquelles mettre sur la prochaine page (staging area), puis tu colles la page dans le cahier (commit dans le repository).
Tu pratiqueras ces commandes en détail au chapitre 2.
Les objets Git
Git stocke les données sous forme de 4 types d'objets. Voici comment ils s'organisent :
commit
a1b2c3d
"Ajouter la page d'accueil"
Auteur: Alice · 14 fév 2026
tree
d4e5f6a
Liste des fichiers du projet
blob
index.html
"<h1>Hello</h1>"
blob
style.css
"body { ... }"
blob — le contenu d'un fichier
Un blob contient le contenu brut d'un fichier. Il ne contient pas le nom du fichier. C'est comme le contenu d'une lettre sans l'enveloppe.
tree — un dossier
Un tree représente un dossier. Il contient une liste de fichiers (blobs) et de sous-dossiers (autres trees). C'est comme la table des matières d'un livre.
commit — une sauvegarde
Un commit est un snapshot complet de ton projet. Il contient :
- - Un lien vers un tree (le contenu du projet)
- - Un message (ce que tu as fait)
- - Un auteur et une date
- - Un ou plusieurs parents (les commits précédents)
tag — une étiquette
Un tag est un nom donné à un commit précis. Par exemple : v1.0 ou v2.3. C'est comme mettre un marque-page dans le cahier.
Comment Git stocke concrètement les données
Voici ce qui se passe réellement quand tu crées un fichier et tu le commites :
# Tu crées un fichier et tu le commites
$ echo "Hello" > hello.txt
$ git add hello.txt
$ git commit -m "Add hello"
# Git a créé 3 objets :
# 1. Un blob (le contenu du fichier)
$ git cat-file -p ce013
Hello
# 2. Un tree (la liste des fichiers)
$ git cat-file -p 8a9f2
100644 blob ce013 hello.txt
# 3. Un commit (le snapshot + métadonnées)
$ git cat-file -p a1b2c
tree 8a9f2
author Alice 1707900000
Add hello
Tu n'as pas besoin de retenir ces commandes. L'important est de comprendre que Git stocke des objets reliés entre eux : le commit pointe vers un tree, le tree pointe vers des blobs.
Le hash : la carte d'identité d'un objet
Mot clé : hash SHA
Un hash est un code unique calculé à partir du contenu d'un objet. C'est comme un code-barre unique sur chaque page du cahier. Deux contenus différents donnent toujours deux hash différents.
Chaque objet Git a un hash unique de 40 caractères. En pratique, on utilise souvent les 7 premiers.
$ git log --oneline
a1b2c3d Ajouter la page d'accueil
e4f5g6h Premier commit
Le hash garantit que les données sont intactes. Si un seul caractère change dans un fichier, le hash sera complètement différent. Impossible de modifier l'historique sans que Git le détecte.
Les branches : des marque-pages
Mot clé : branche
Une branche est un nom qui pointe vers un commit. Dans notre cahier, c'est un marque-page. Le marque-page dit : "je suis à cette page". Quand tu ajoutes une nouvelle page, le marque-page se déplace.
Une branche n'est pas une copie du code. C'est juste un petit fichier qui contient le hash d'un commit. Créer une branche est instantané.
# Deux marque-pages dans le cahier
main → a1b2c3d (page 3)
feature → e4f5g6h (page 5)
HEAD → main (tu lis la page du marque-page "main")
Le graphe des branches :
→ C → D → E (feature)
/
A → B → C (main, HEAD)
Concrètement, Git stocke chaque branche comme un fichier dans le dossier .git/refs/heads/ :
$ cat .git/refs/heads/main
a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0
# C'est tout. Un fichier de 40 caractères.
Tu créeras et fusionneras des branches au chapitre 3.
HEAD : la page ouverte
Mot clé : HEAD
HEAD est un pointeur qui dit "tu es ici". Dans notre cahier, c'est la page que tu as ouverte. En général, HEAD pointe vers une branche (un marque-page).
Quand tu fais un nouveau commit, la branche avance. Et HEAD suit la branche.
# Avant le commit :
HEAD → main → a1b2c3d
# Après le commit :
HEAD → main → f7a8b9c → a1b2c3d
Parfois, HEAD peut être "détaché" (detached HEAD). Cela veut dire que HEAD pointe directement vers un commit, sans passer par une branche. C'est utile pour regarder un ancien commit. Mais attention : si tu fais des commits dans cet état, ils peuvent être perdus (aucun marque-page ne pointe dessus).
Le graphe Git
Mot clé : graphe (DAG)
L'historique de Git forme un graphe. Chaque commit pointe vers son parent (le commit précédent). C'est comme un arbre généalogique : chaque enfant connaît ses parents.
Tu peux voir le graphe avec cette commande :
$ git log --graph --oneline --all
* f7a8b9c (HEAD → main) Merge branch 'feature'
|\
| * d4e5f6a (feature) Add feature
|/
* a1b2c3d Initial commit
Local vs Distant
Ton dépôt Git est sur ta machine. C'est ton dépôt local.
Un dépôt distant (remote) est une copie du projet sur un serveur. Par exemple sur GitHub, GitLab ou Bitbucket.
Dans notre analogie, c'est comme si ton collègue avait son propre cahier de photographe. Vous pouvez vous envoyer des pages :
git push
Tu envoies tes nouvelles pages vers le cahier partagé
git pull
Tu récupères les nouvelles pages du cahier partagé
git push : envoyer tes commits
Quand tu as fait un ou plusieurs commits en local, tu peux les envoyer vers le dépôt distant avec git push.
$ git push
# Envoie tes commits locaux vers le dépôt distant
# Les autres membres de l'équipe pourront voir tes changements
git pull : récupérer les nouveautés
Quand d'autres personnes ont poussé des commits sur le dépôt distant, tu peux les récupérer avec git pull. Cette commande fait deux choses : elle télécharge les nouveaux commits (fetch) puis les intègre dans ta branche (merge).
$ git pull
# Récupère les commits distants et les intègre à ta branche
remote: Counting objects: 3, done.
From github.com:user/projet
a1b2c3d..f4e5d6a main → origin/main
Updating a1b2c3d..f4e5d6a
Fast-forward
readme.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Bonne pratique
Fais un git pull avant de commencer à travailler. Ça te garantit d'avoir la dernière version du projet. Tu éviteras des conflits inutiles.
L'important à retenir : tu peux travailler sans connexion internet. Tu synchronises quand tu veux avec push et pull.
En résumé
Voici comment tous les concepts de ce chapitre s'emboîtent :
Tu modifies des fichiers dans le Working Directory
Tu prépares les fichiers dans la Staging Area
Git crée un commit (snapshot) dans le Repository
Des objets (blob, tree, commit) identifiés par des hash SHA
Des branches (pointeurs) dont une est active via HEAD
Un graphe (DAG) qui est l'historique complet du projet
Erreurs fréquentes
- ●Confondre Git et GitHub. Git est l'outil. GitHub est un site web.
- ●Croire qu'un commit ne sauvegarde que les modifications. Non, c'est une photo complète (snapshot).
- ●Penser que les branches sont des copies du code. Ce sont juste des pointeurs (des marque-pages).
- ●Ne pas comprendre que HEAD peut être détaché. Si tu fais un commit sans branche, il peut être perdu.
- ●Oublier la staging area. Les fichiers ne sont pas sauvegardés tant que tu ne fais pas git add puis git commit.
Pour aller plus loin
Teste tes connaissances
Avant de passer aux exercices, vérifie que tu as compris les concepts. Clique sur la réponse qui te semble correcte.
Quiz — Chapitre 1
1. Un blob Git contient…
2. Comment Git sauvegarde-t-il tes fichiers ?
3. Qu'est-ce qu'une branche Git ?
4. Quand HEAD est détaché et que tu fais un commit…
Pour aller plus loin
Ce chapitre couvre les fondamentaux du modèle Git. Si tu veux approfondir, voici quelques pistes :
- ●SHA-1 vs SHA-256 : Git utilisait SHA-1 pour calculer les hash. Il migre progressivement vers SHA-256, plus sécurisé. Le fonctionnement reste identique.
- ●Garbage collection : Git nettoie automatiquement les objets qui ne sont plus référencés par aucune branche ou tag. C'est pour ça qu'un commit en "detached HEAD" peut être perdu.
- ●Pro Git : le livre gratuit de référence sur Git (en anglais). Disponible en ligne sur git-scm.com/book.
- ●Documentation officielle : git-scm.com/doc pour la référence complète de toutes les commandes Git.
Ton avis compte
Aide-nous à améliorer cette formation en partageant ton retour.