git commit, push et pull : quelle différence ?

En une phrase : git commit enregistre tes modifications dans ton dépôt local, git push envoie ces commits vers le dépôt distant (GitHub, GitLab…), et git pull récupère les commits du dépôt distant pour les intégrer à ta branche.

Les trois commandes se suivent dans la journée d'un ou d'une dev, mais elles n'agissent pas au même endroit. C'est exactement ce qui crée la confusion au début : on croit avoir « envoyé » son travail alors qu'il n'a jamais quitté son ordinateur.

Le schéma à garder en tête

Git est un outil distribué : ton ordinateur contient une copie complète du projet, avec tout son historique. Le dépôt distant n'est qu'une autre copie, partagée avec le reste de l'équipe. Une modification passe donc par plusieurs étapes avant d'être visible par les autres.

Retiens surtout la frontière entre « ta machine » et « en ligne » : seules git push et git pull la traversent.

git commit : enregistrer une étape, en local

Un commit est une photo de tes fichiers à un instant donné, accompagnée d'un message, d'un auteur et d'une date. Avant de commiter, tu choisis ce qui entre dans la photo avec git add.

$ git statusOn branch mainChanges not staged for commit:        modified:   contact.html $ git add contact.html$ git commit -m "Ajoute le formulaire de contact"[main 3f2a9c1] Ajoute le formulaire de contact 1 file changed, 12 insertions(+)

Ce qu'il faut retenir :

• Un commit ne quitte jamais ta machine. Tu peux commiter dans le train, sans réseau : tout se passe en local.
• Seuls les fichiers ajoutés avec git add entrent dans le commit. Un fichier modifié mais pas ajouté reste en dehors.
• Un commit est quasiment impossible à perdre, même après une fausse manœuvre : c'est pour ça qu'on conseille de commiter souvent, par petites étapes.

Pour aller plus loin sur cette commande, lis git commit expliqué et les bonnes pratiques pour écrire un message de commit.

git push : envoyer tes commits

git push envoie au dépôt distant les commits qu'il n'a pas encore. C'est à ce moment-là, et seulement à ce moment-là, que ton travail devient visible pour l'équipe.

$ git push origin main# (sortie raccourcie)To github.com:camille/mon-site.git   8b1d2e4..3f2a9c1  main -> main

La ligne 8b1d2e4..3f2a9c1 main -> main se lit ainsi : la branche main du dépôt distant est passée du commit 8b1d2e4 au commit 3f2a9c1, ton nouveau commit.

Deux situations reviennent souvent :

• Première fois sur une nouvelle branche : tape git push -u origin ma-branche. L'option -u relie ta branche locale à la branche distante, et tu pourras ensuite taper git push tout court.
• Rien à envoyer : si tu n'as pas fait de nouveau commit, Git répond Everything up-to-date. Des fichiers modifiés mais pas commités ne partent pas avec git push.

Quand git push est refusé

Si quelqu'un a poussé sur la même branche avant toi, le dépôt distant contient des commits que tu n'as pas. Git refuse alors d'écraser son travail :

$ git push ! [rejected]        main -> main (fetch first)error: failed to push some refs to 'github.com:camille/mon-site.git'hint: Updates were rejected because the remote contains work that you do nothint: have locally.

La solution n'est pas de forcer, mais de récupérer d'abord le travail des autres avec git pull, puis de pousser à nouveau. Le détail est dans notre fiche sur l'erreur failed to push some refs.

git pull : récupérer le travail des autres

git pull fait deux choses à la suite :

1. git fetch : il télécharge les nouveaux commits du dépôt distant ;
2. git merge : il les fusionne dans ta branche actuelle (ou git rebase, si tu l'as configuré ainsi).

$ git pullUpdating 3f2a9c1..7c4e8d0Fast-forward README.md | 4 ++++ 1 file changed, 4 insertions(+)

Fast-forward signifie que tu n'avais rien fait de ton côté depuis : Git a simplement avancé ta branche jusqu'aux nouveaux commits. Si vous avez modifié les mêmes lignes de part et d'autre, Git te demande de choisir : c'est un conflit, et on t'explique comment résoudre un conflit de merge pas à pas.

Deux messages que tu croiseras sûrement :

• Your local changes to the following files would be overwritten by merge : tu as des modifications non commitées sur des fichiers que git pull doit mettre à jour. Commite-les (ou mets-les de côté avec git stash), puis relance git pull. Voir local changes would be overwritten.
• fatal: Need to specify how to reconcile divergent branches : ta branche et la branche distante ont chacune des commits que l'autre n'a pas, et les versions récentes de Git refusent de choisir entre merge et rebase à ta place. Tape une fois git config --global pull.rebase false pour garder le comportement classique (merge).

Et si tu veux regarder ce qui a changé avant de fusionner, utilise git fetch seul : on compare les deux dans git pull vs git fetch.

Dans quel ordre taper ces commandes ?

Voici la routine d'une journée de travail sur un projet partagé :

# En arrivant : récupérer ce que l'équipe a poussé$ git pull # Pendant la journée : travailler, puis enregistrer par petites étapes$ git add contact.html$ git commit -m "Ajoute la validation du formulaire" # Avant de partager : récupérer les derniers changements, puis envoyer$ git pull$ git push

Le réflexe à prendre : git pull avant git push. Tu intègres d'abord le travail des autres, tu vérifies que tout fonctionne, puis tu envoies le tien.

Les quatre confusions les plus fréquentes

• « J'ai commité, donc c'est sur GitHub. » Non : le commit est local. Sans git push, personne d'autre ne le voit, et il n'est pas sauvegardé ailleurs que sur ton ordinateur.
• « git push envoie mes fichiers modifiés. » Non : il envoie des commits. Un fichier modifié mais pas commité reste sur ta machine.
• « git pull va écraser mon travail. » Non : il fusionne. Si une fusion risquait d'écraser des modifications non commitées, Git s'arrête et te prévient au lieu de les effacer.
• « Il faut pousser après chaque commit. » Pas obligatoirement. Commite souvent, et pousse quand ton travail peut être partagé, ou simplement pour en garder une copie en ligne sur ta propre branche.

Questions fréquentes

Peut-on faire git push sans git commit ?

Non. git push envoie des commits, pas des fichiers. Sans nouveau commit, Git répond Everything up-to-date, même si tu as des fichiers modifiés.

Est-ce que git commit envoie mon code sur GitHub ?

Non. git commit enregistre une étape dans ton dépôt local uniquement. C'est git push qui envoie tes commits sur GitHub, GitLab ou tout autre dépôt distant.

Faut-il faire git pull avant git push ?

C'est la bonne habitude. Si quelqu'un a poussé sur ta branche entre-temps, Git refusera ton git push tant que tu n'auras pas récupéré ses commits avec git pull.

Quelle est la différence entre git pull et git fetch ?

git fetch télécharge les nouveaux commits du dépôt distant sans toucher à ta branche. git pull fait un git fetch puis fusionne directement ces commits dans ta branche.

À quelle fréquence faut-il commiter ?

Dès que tu as terminé une petite étape cohérente : une fonction qui marche, un bug corrigé, un texte relu. Des commits petits et fréquents sont plus faciles à comprendre, à relire et à annuler.