Avant ton premier commit : installe Git et présente-toi
Avant de lancer la moindre commande, vérifie que Git est présent sur ta machine :
git --version
# git version 2.45.2Sur macOS et la plupart des distributions Linux, Git est déjà installé. Sinon, deux lignes suffisent :
- macOS (Homebrew) :
brew install git - Ubuntu / Debian :
sudo apt install git - Windows : télécharge l'installateur sur git-scm.com
Une fois Git installé, présente-toi à lui. C'est obligatoire : chaque commit est signé avec ton nom et ton email, et Git refuse de committer sans cette identité.
git config --global user.name "Ton Nom"
git config --global user.email "ton@email.fr"Pour vérifier que tout est en place :
git config --list
# user.name=Ton Nom
# user.email=ton@email.frLe flag --global enregistre ces réglages une fois pour toutes sur ta machine, pour tous tes projets. Et l'email que tu renseignes ici est précisément celui que GitHub utilise pour relier tes commits à ton profil : c'est la connexion concrète qu'on retrouvera dans la leçon sur GitHub et le dépôt distant.
Maintenant que Git te connaît, on peut créer le dépôt et faire ton premier commit.
« J'ai un projet, et maintenant ? »
Vous avez compris pourquoi Git existe. Reste à l'utiliser pour de vrai. La bonne nouvelle : 90 % du travail quotidien tient dans une boucle de cinq commandes, toujours les mêmes.
Vous modifiez des fichiers, vous regardez ce qui a changé, vous sélectionnez ce que vous voulez enregistrer, vous prenez la photo, et vous vérifiez l'historique. Encore et encore. Une fois ce réflexe acquis, Git devient une seconde nature.
On va dérouler cette boucle pas à pas sur un mini-projet.
Les trois zones de Git
Pour comprendre les commandes, il faut d'abord visualiser les trois endroits où vivent vos fichiers :
Un changement voyage de gauche à droite : vous éditez un fichier (répertoire de travail), vous le placez dans la zone de staging avec git add, puis vous le figez dans le dépôt avec git commit. La zone de staging est ce qui rend Git si précis : vous choisissez exactement ce qui entre dans chaque photo.
git add puis git commit.La boucle complète, en vrai
Voici une session réelle, du dossier vide au premier commit :
Avant de dérouler : vous venez de modifier index.html, puis vous lancez git commit -m "maj" sans avoir fait git add avant. Votre modification est-elle enregistrée dans le commit ? Pourquoi Git fonctionne-t-il ainsi ?
Voir la réponse
Non, votre modification n'est pas dans le commit. Un git commit n'enregistre que ce qui a été placé dans la zone de staging avec git add : sans git add index.html au préalable, la modification reste dans votre répertoire de travail et le commit l'ignore (Git vous affiche d'ailleurs « Changes not staged for commit »). Cette étape intermédiaire est volontaire : elle vous laisse choisir précisément ce qui entre dans chaque commit, par exemple ne committer qu'une partie de vos changements. Raccourci pratique : git commit -a -m "..." ajoute automatiquement les fichiers déjà suivis qui ont changé, mais un fichier tout neuf (non suivi) doit toujours passer par git add.
$ git init
Initialized empty Git repository in /home/alice/mon-site/.git/
$ touch index.html
$ git status
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
index.html
$ git add index.html
$ git commit -m "Ajoute la page d'accueil"
[main (root-commit) a1b2c3d] Ajoute la page d'accueil
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 index.html
$ git log --oneline
a1b2c3d Ajoute la page d'accueilgit init crée le dépôt (un dossier caché .git). git status montre l'état des fichiers à tout moment : c'est la commande que vous taperez le plus souvent. git add place un fichier en staging. git commit -m fige le tout avec un message. git log affiche l'historique.
Écrire de bons messages de commit
Le message de commit explique pourquoi ce changement existe. Dans six mois, c'est lui qui vous sauvera. Comparez :
Mauvais
update
fix
truc
aaa
Bon
Ajoute la validation de l'email du formulaire
Corrige le calcul de TVA arrondi au centime
La convention : un verbe à l'impératif, une ligne courte et précise. « Ajoute », « Corrige », « Supprime ». On décrit l'effet du commit, pas le détail technique.
Commitez petit et souvent. Un commit = un changement logique cohérent. Plutôt que dix modifications dans un seul commit géant, faites dix petits commits ciblés. C'est plus facile à relire, à comprendre, et à annuler si l'un d'eux pose problème.
Before your first commit: install Git and introduce yourself
Before running any command, check that Git is available on your machine:
git --version
# git version 2.45.2On macOS and most Linux distributions, Git is already installed. Otherwise, two lines are enough:
- macOS (Homebrew):
brew install git - Ubuntu / Debian:
sudo apt install git - Windows: download the installer from git-scm.com
Once Git is installed, introduce yourself to it. This is mandatory: every commit is signed with your name and email, and Git will refuse to commit without this identity.
git config --global user.name "Your Name"
git config --global user.email "you@email.com"To check that everything is in place:
git config --list
# user.name=Your Name
# user.email=you@email.comThe --global flag saves these settings once and for all on your machine, for all your projects. And the email you set here is exactly the one GitHub uses to link your commits to your profile; that connection will come up again in the GitHub and remotes lesson.
Now that Git knows who you are, let's create the repository and make your first commit.
"I have a project, now what?"
You understood why Git exists. Now you need to actually use it. The good news: 90% of daily work fits in a loop of five commands, always the same ones.
You edit files, you look at what changed, you select what you want to save, you take the snapshot, and you check the history. Again and again. Once this reflex sets in, Git becomes second nature.
Let's walk through this loop step by step on a mini-project.
Git's three areas
To understand the commands, you first need to picture the three places where your files live:
A change travels from left to right: you edit a file (working directory), you place it in the staging area with git add, then you freeze it in the repository with git commit. The staging area is what makes Git so precise: you choose exactly what goes into each snapshot.
git add then git commit.The full loop, for real
Here is a real session, from an empty folder to the first commit:
Before you scroll down: you just edited index.html, then you run git commit -m "update" without having done git add first. Is your change saved in the commit? Why does Git work this way?
See the answer
No, your change is not in the commit. A git commit only records what was placed in the staging area with git add: without git add index.html beforehand, the change stays in your working directory and the commit ignores it (Git will even tell you "Changes not staged for commit"). This intermediate step is intentional: it lets you choose precisely what goes into each commit, for example committing only part of your changes. Practical shortcut: git commit -a -m "..." automatically stages already-tracked files that have changed, but a brand-new file (untracked) always needs git add first.
$ git init
Initialized empty Git repository in /home/alice/my-site/.git/
$ touch index.html
$ git status
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
index.html
$ git add index.html
$ git commit -m "Add the homepage"
[main (root-commit) a1b2c3d] Add the homepage
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 index.html
$ git log --oneline
a1b2c3d Add the homepagegit init creates the repository (a hidden .git folder). git status shows the state of files at any time: the command you will type most often. git add stages a file. git commit -m freezes everything with a message. git log shows the history.
Writing good commit messages
The commit message explains why this change exists. In six months, it is what will save you. Compare:
Bad
update
fix
stuff
aaa
Good
Add email validation to the form
Fix VAT rounding to the cent
The convention: an imperative verb, a short and precise line. "Add", "Fix", "Remove". You describe the effect of the commit, not the technical detail.
Commit small and often. One commit = one coherent logical change. Rather than ten edits in a single giant commit, make ten small focused commits. It is easier to review, to understand, and to undo if one of them causes a problem.
🎯 Pratique
S'entraîner (clique pour ouvrir) :
✨ Prompt IA
Vous ne savez pas comment résumer vos changements ? Collez le résultat de git diff à l'IA :
Voici le résultat de ma commande git diff (je vais le coller en dessous). Propose-moi trois messages de commit possibles, en français, à l'impératif, en une seule ligne courte chacun, qui décrivent le pourquoi du changement et pas seulement le quoi. Explique en une phrase lequel des trois tu recommandes.
💬 Ré-explique sans regarder
Sans relire ci-dessus : pourquoi colle-t-on le résultat de git diff à l'IA pour rédiger un message de commit, et pourquoi reste-t-on celui qui choisit le message final ?
git diff montre exactement les lignes changées, donc l'IA a le contexte réel et ne devine pas. Mais l'IA voit le quoi, pas le pourquoi : c'est toi qui sais l'intention. Tu pars de ses propositions à l'impératif, tu gardes celle qui décrit l'effet du changement, et tu la corriges si besoin. L'IA accélère la rédaction, elle ne décide pas à ta place.Écrivez la suite de commandes pour : initialiser un dépôt, ajouter le fichier index.html en staging, et créer un commit avec un message clair. Utilisez git init, git add et git commit -m.
⚖️ Juge le code de l'IA
L'IA a corrigé un arrondi de TVA et te propose ce commit. Ton rôle de relecteur : l'accepter tel quel ou le rejeter, et dire pourquoi.
$ git add .
$ git commit -m "fix""fix" n'apprend rien ; dans six mois personne ne saura quel bug a été corrigé. Il fallait quelque chose comme "Corrige l'arrondi de TVA au centime". Ensuite le git add . : il met en staging tout le répertoire, y compris des fichiers qui n'ont rien à voir avec ce correctif. Le réflexe pro : commiter petit et ciblé, et git add uniquement les fichiers concernés.🧠 Rappel libre
Sans remonter dans la leçon : nomme les trois zones de Git dans l'ordre, et dis quelle commande fait passer un fichier de l'une à la suivante.
git add fait passer un fichier du répertoire de travail vers la staging ; git commit fige le contenu de la staging dans le dépôt.Vous savez enregistrer votre travail commit après commit, avec des messages clairs. Mais comment tester une nouvelle idée sans risquer de casser ce qui marche déjà ? La prochaine leçon ouvre les branches, ces lignes de temps parallèles où vous expérimentez en toute sécurité.
Leçon 5 : Les branches →