Tutoriel Git : les commandes de base (add, commit, push, pull)

Cinq commandes suffisent à travailler au quotidien : status, add, commit, push et pull. Ce chapitre les prend une par une, puis aborde ce qu’aucun tutoriel ne devrait sauter : comment revenir en arrière quand vous vous êtes trompé.

Une condition préalable : votre identité doit être déclarée, sans quoi Git refusera votre premier commit. Si ce n’est pas fait, revenez au chapitre d’installation.

Les trois zones de Git

Tout devient plus simple une fois qu’on a compris que vos fichiers se trouvent dans l’une de trois zones.

• Le répertoire de travail : vos fichiers tels que vous les voyez dans l’explorateur.
• L’index, aussi appelé staging area : la liste de ce qui partira dans le prochain commit. git add y place les modifications.
• Le dépôt : l’historique des commits, ce que git commit alimente.

Cette zone intermédiaire déroute au début, mais c’est elle qui permet d’enregistrer trois modifications sur cinq et de garder les deux autres pour un commit séparé.

git status, la commande à taper tout le temps

Elle vous dit où vous en êtes, et ses messages contiennent presque toujours la commande à taper ensuite. Prenez l’habitude de la lancer avant et après chaque opération.

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.env
	app.js
	node_modules/

nothing added to commit but untracked files present (use "git add" to track)

La version courte tient sur une ligne par fichier et devient vite votre réflexe :

git status --short

?? .env
?? app.js
?? node_modules/

?? signale un fichier que Git ne suit pas encore, A un fichier ajouté à l’index, M un fichier modifié.

.gitignore : ce qui ne doit jamais partir

Avant même le premier git add, écartez ce qui n’a rien à faire dans un dépôt : les dépendances réinstallables, les fichiers de configuration contenant des secrets, les fichiers générés par votre système ou votre éditeur.

Créez un fichier .gitignore à la racine du projet :

node_modules/
vendor/
.env
.env.local
dist/
build/
*.log
.DS_Store
.idea/
.vscode/

Relancez git status : les fichiers ignorés ont disparu de la liste.

?? .gitignore
?? app.js

Le .gitignore, lui, est versionné : il fait partie du projet et doit être partagé avec l’équipe.

Attention à un piège : .gitignore n’a aucun effet sur un fichier déjà suivi. Si vous avez committé un .env avant d’y penser, il faut le retirer explicitement de l’index :

git rm --cached .env
git commit -m "Retire le fichier .env du suivi"

L’option --cached est essentielle : elle retire le fichier de l’index sans le supprimer de votre disque.

Et considérez les secrets qu’il contenait comme compromis : ils restent lisibles dans l’historique. Changez-les.

git add : préparer le commit

git add app.js          # un fichier
git add src/            # un dossier entier
git add .               # tout ce qui a changé sous le dossier courant
git add -p              # choisir morceau par morceau, de façon interactive

git add -p mérite d’être essayé tôt. Git vous présente chaque bloc de modification et vous demande si vous le voulez dans le commit. C’est le moyen le plus simple de produire des commits qui racontent une seule chose.

git commit : enregistrer

git commit -m "Ajoute la page d'accueil"

[main (root-commit) fd4fdb7] Ajoute la page d accueil
 2 files changed, 3 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 app.js

Si rien n’est dans l’index, Git ne crée rien et vous le dit :

On branch main

Initial commit

nothing to commit (create/copy files and use "git add" to track)

Sur les messages de commit, une seule règle vaut la peine d’être retenue : écrivez ce que fait le commit, pas ce que vous avez touché. « Corrige le calcul de la TVA sur les commandes hors UE » vaut mieux que « modif facture.php ». Vous écrivez pour vous-même dans six mois.

Le raccourci -am combine add et commit, mais seulement pour les fichiers déjà suivis :

git commit -am "Corrige le libellé du bouton"

Lire l’historique

git log                                  # complet
git log --oneline                        # une ligne par commit
git log --oneline --graph --decorate     # avec la forme des branches
git log -p app.js                        # l'historique d'un seul fichier, avec les diffs

* fd4fdb7 (HEAD -> main) Ajoute la page d accueil

HEAD désigne l’endroit où vous vous trouvez dans l’historique. La flèche indique que HEAD suit la branche main.

Voir ses modifications avant de committer

Deux commandes, souvent confondues, qui regardent deux zones différentes.

git diff            # ce qui a changé mais n'est pas encore dans l'index
git diff --staged   # ce qui est dans l'index et partira au prochain commit

diff --git a/app.js b/app.js
index e921523..ebde020 100644
--- a/app.js
+++ b/app.js
@@ -1 +1 @@
-console.log('hello');
+console.log('bonjour');

Après un git add app.js, la même modification bascule : git diff ne renvoie plus rien, et git diff --staged affiche le bloc. C’est la meilleure façon de visualiser l’index.

git push et git pull : échanger avec le serveur

git push        # envoyer les commits locaux
git pull        # récupérer et intégrer ceux des autres

Ces deux formes courtes ne fonctionnent que si la branche a un lien vers le serveur, établi par le -u du chapitre précédent. Pour vérifier ce lien :

git branch -vv

* feature/panier bc2203a Page d accueil
  main           bc2203a [origin/main] Page d accueil

La branche main suit origin/main, la branche feature/panier ne suit rien pour l’instant.

Si quelqu’un a poussé pendant que vous travailliez, votre push est refusé. La marche à suivre et l’explication complète sont dans le chapitre sur les branches.

Annuler une bêtise

C’est la partie que les débutants cherchent le plus souvent, et qu’on leur explique le moins. Le bon réflexe consiste d’abord à répondre à une question : ce que je veux annuler est-il déjà parti sur le serveur ?

Le fichier est modifié, je veux revenir au dernier commit

git restore app.js       # un fichier
git restore .            # tout le répertoire de travail

Attention, cette commande détruit vos modifications sans filet : elles n’ont jamais été enregistrées nulle part, Git ne peut pas les retrouver.

J’ai fait git add trop vite

git restore --staged app.js

Le fichier sort de l’index, vos modifications restent intactes dans le répertoire de travail.

Ces deux commandes sont l’équivalent moderne de git checkout -- fichier et git reset HEAD fichier. git restore existe depuis Git 2.23 et dit clairement ce qu’il fait, là où checkout et reset font chacun trois choses différentes selon les options.

Le message de mon dernier commit est mauvais

git commit --amend -m "Le bon message"

La même commande sert à ajouter un fichier oublié : faites votre git add, puis relancez git commit --amend. Ne l’utilisez que sur un commit qui n’a pas encore été poussé : --amend ne modifie pas le commit, il en crée un nouveau à la place, et l’ancien identifiant disparaît.

Le commit est déjà poussé, je veux le défaire proprement

git revert HEAD

[main 0246de1] Revert "Ajoute un fichier par erreur"
 1 file changed, 1 deletion(-)
 delete mode 100644 bug.txt

git revert crée un nouveau commit qui applique l’inverse du précédent. L’historique s’allonge au lieu d’être réécrit, ce qui est exactement ce qu’il faut quand d’autres personnes ont déjà récupéré votre travail. C’est la seule méthode sans danger sur une branche partagée.

Le commit n’est pas poussé, je veux le supprimer

git reset --soft HEAD~1   # défait le commit, garde tout dans l'index
git reset --mixed HEAD~1  # défait le commit, garde les fichiers modifiés (comportement par défaut)
git reset --hard HEAD~1   # défait le commit et supprime les modifications

--soft est le plus utile : il vous rend vos modifications prêtes à être recommittées autrement. --hard est le seul qui détruit du travail, et il ne prévient pas. Ne le tapez que si vous êtes certain.

J’ai fait un reset –hard de trop

Tout n’est pas perdu. Git conserve pendant plusieurs semaines la trace de tous les états par lesquels HEAD est passé :

git reflog

8207e54 HEAD@{0}: reset: moving to HEAD~2
f3951da HEAD@{1}: commit: Version 3
8ac671c HEAD@{2}: commit: Version 2
8207e54 HEAD@{3}: commit (initial): Version 1

Les deux commits effacés sont toujours là. Repérez la ligne correspondant à l’état voulu, notez son identifiant, et revenez-y :

git reset --hard f3951da

Le reflog ne rattrape en revanche que ce qui avait été committé. Des modifications jamais enregistrées sont définitivement perdues, ce qui est un argument de plus pour committer souvent.

Le résumé

Vous savez travailler seul. Le chapitre suivant ajoute les autres : branches, fusions et conflits. Le dernier chapitre traitera ensuite de l’organisation de ces branches à l’échelle d’une équipe.