Git pour Builders Débutants : Comprendre Enfin Comment Ça Marche

En construisant Parhelio avec Next.js, j’ai dû enfin comprendre Git. Voici la version claire que j’aurais aimé lire : moins de jargon, plus de logique.

---

Je suis Product Manager depuis 12 ans. J'ai collaboré avec des dizaines de devs. J'ai entendu "commit", "push", "merge" des milliers de fois.

Mais je n'avais jamais vraiment compris Git. Pas conceptuellement. Je savais que ça versionnait du code, mais je ne comprenais pas pourquoi il y avait plusieurs étapes pour sauvegarder, ni ce qui se passait vraiment quand on "pushait".

Quand j'ai décidé de construire Parhelio avec Next.js et Claude Code, impossible d'y échapper. J'ai lu des tutoriels qui partaient du principe que je savais déjà ce qu'était un "repository" ou une "staging area". Aucun ne m'expliquait les fondamentaux de façon honnête.

Cet article, c'est ce que j'aurais voulu lire.

Il ne fait pas de toi un expert Git. Mais il t'explique comment ça fonctionne réellement, et les 3 commandes dont tu as besoin pour démarrer.

---

C'est quoi Git enfait ?

Git = un système de sauvegarde intelligent pour ton code.

Sans Git, on se retrouve vite avec ça :

chapitre1_v1.docx
chapitre1_v2.docx
chapitre1_v2_final.docx
chapitre1_v2_final_VRAIMENT.docx

Git fait la même chose, mais en mieux :

• Il garde l'historique de toutes tes versions
• Tu peux revenir à n'importe quelle version, surtout si tu casses quelque chose
• Tu sais exactement ce qui a changé entre deux versions
• Tu peux travailler sur plusieurs versions en parallèle (branches)

En gros, tu construis ton projet et à certains moments, tu prends une photo de son état.

Cette photo :

• garde une trace de ce qui existe à cet instant
• te permet de revenir en arrière
• te permet de comparer avant / après

Chaque "photo" du code à un instant donné s'appelle un commit.

Je trouve cette analogie utile parce qu'elle montre quelque chose d'essentiel :

Git ne sert pas seulement à collaborer. Il sert d'abord à stabiliser ton rapport à ce que tu construis.

---

Le point qui change tout : Git est local

Pendant longtemps, j'ai confondu Git et GitHub. Or Git vit d'abord sur ton ordinateur.

Tu peux utiliser Git 100% hors ligne : modifier du code, commit, voir tout l'historique, revenir en arrière. Sans connexion.

Quand tu initialises Git dans un projet, il crée un dossier caché .git/ qui contient l'historique local.

Je m'en sers d'ailleurs pour mon "Second Brain" sur Obsidian. Toutes les 30 minutes, j'ai un 'commit' automatique qui sauvegarde les modifications faites sur mes notes.

GitHub vient ensuite.

Cette distinction est importante parce qu'elle remet chaque chose à sa place.

Git vs GitHub

Git : logiciel installé sur ton ordinateur, gère l'historique localement, open-source.

GitHub : site web qui héberge une copie de ton historique Git dans le cloud pour le backup, la collaboration, et le déploiement.

Dans mon cas, pour Parhelio, il y a trois lieux à distinguer :

1. Obsidian où je travaille
2. Github, où le projet est sauvegardé à distance
3. Vercel, qui déploie le site en ligne

Le mouvement ressemble donc à ça :

Obsidian
    ↓ git push
GitHub
    ↓ déploiement
Vercel

Cette chaîne paraît simple une fois comprise. Avant ça, elle est étonnamment floue.

Les 3 commandes qui comptent vraiment au début

Quand on débute, on n'a pas besoin de comprendre tout Git. On a surtout besoin de comprendre un petit workflow stable.

1. "git add ." Choisir ce qu'on veut sauvegarder

Analogie : préparer un carton pour La Poste. Tu choisis ce que tu veux envoyer et tu le mets dans le carton. Le carton n'est pas encore fermé.

git add .

Le . signifie "tout". Tu mets tous les fichiers modifiés dans le carton.

2. git commit -m "Message"

Tu fermes et scelles le carton. Tu écris dessus une description de ce qu'il contient.

git commit -m "Add header and footer components"

Le message doit t'aider, plus tard, à comprendre ce que tu as fait.

Le message décrit ce que tu as fait. Dans 6 mois, tu dois comprendre ce commit sans ouvrir le code.

3. git push - Envoyer sur GitHub

Tu apportes ton carton scellé à La Poste (ou plutôt GitHub)

git push

À partir de là, ton projet n'existe plus seulement sur ta machine. Il est aussi sauvegardé à distance.

---

Le workflow complet qui suffit pour démarrer

Le petit rituel qui m'a suffi pour commencer est celui-ci :

git status              # Voir ce qui a changé (optionnel mais utile)
git add .               # Mettre dans le carton
git commit -m "Message" # Fermer le carton
git push                # Envoyer sur GitHub

git status n'est pas obligatoire, mais il aide à voir ce qui a changé avant de figer quoi que ce soit.

Ce workflow n'a rien de sophistiqué. Mais il suffit déjà à travailler avec beaucoup moins d'appréhension.

Pourquoi add ET commit ? (la question que tout le monde se pose)

Parce que tu ne veux pas toujours tout sauvegarder d'un coup.

Si tu as modifié 10 fichiers — 5 pour le Header, 5 pour le Footer — tu peux faire deux commits séparés :

# Commit 1 : Header
git add components/Header.tsx app/header.css
git commit -m "Add Header component"

# Commit 2 : Footer
git add components/Footer.tsx app/footer.css
git commit -m "Add Footer component"

git push

Si le Footer plante en prod et que tu veux revenir en arrière, tu annules juste le commit Footer. Le Header reste intact. Avec un seul gros commit, tu serais obligé de tout annuler.

Ce qu'il ne faut pas faire

Ne jamais commiter ses secrets. API keys, tokens, mots de passe — si le repo devient public, tout le monde les voit. Solution : utilise .env.local pour les secrets. Ce fichier est ignoré par Git par défaut avec Next.js.

Ne jamais commiter node_modules/. Des milliers de fichiers inutiles à versionner. Le .gitignore de Next.js l'exclut automatiquement.

Ne jamais utiliser git push --force sauf si tu sais exactement ce que tu fais. Ça écrase l'historique. on exécute des commandes comme des formules magiques.

Ce que Git a changé pour moi

Comprendre Git ne m'a pas seulement aidé à utiliser une commande de plus. Ça m'a surtout permis de me sentir moins extérieur à ce que je construisais.

Tant que Git restait une boîte noire, j'avais l'impression de bricoler autour d'un système que d'autres maîtrisaient pour moi.

À partir du moment où sa logique est devenue lisible, le sujet a cessé d'être impressionnant.

Le vrai problème, au fond, n'était pas la difficulté. C'était l'opacité.

Et je trouve que ça vaut pour beaucoup d'outils techniques quand on débute.

---

Ressources :

• Learn Git Branching — tutoriel interactif visuel
• GitHub Desktop — interface graphique gratuite
• GitHub Docs — documentation officielle