Le remote origin est configuré depuis le guide précédent, mais le dépôt GitHub est toujours vide. Ce guide contient l'action qui change ça : git push.

Ce que push envoie, et ce qu'il n'envoie pas

git push envoie des commits, pas des fichiers isolés. Concrètement, si vous avez modifié un fichier sur votre disque sans l'avoir ni ajouté avec git add ni enregistré avec git commit, cette modification ne partira pas sur GitHub, même après un push. Seul ce qui a déjà été committé localement peut être poussé. C'est une conséquence directe du modèle vu au tout premier guide : fichiers de travail, staging area, commit local, puis seulement ensuite, dépôt distant.

Le premier push

Vérifiez d'abord votre état local, par réflexe.

Tout est propre, tous vos commits locaux sont prêts à partir. Envoyez-les avec la commande suivante.

Décomposons cette commande. origin désigne le remote configuré au guide précédent. main précise la branche locale à envoyer. L'option -u (pour « upstream ») fait plus que ce simple envoi : elle indique à Git que votre branche locale main doit désormais être associée à origin/main. Concrètement, cela signifie que les prochains push ou pull sur cette branche n'auront plus besoin de préciser origin main : un simple git push suffira.

Selon votre méthode de connexion GitHub, une fenêtre d'authentification peut s'ouvrir la première fois, dans votre navigateur ou directement dans le terminal. Suivez les instructions affichées pour confirmer votre identité.

Vérifier directement sur GitHub

Retournez sur la page de votre dépôt dans un navigateur, et actualisez-la. Vos trois fichiers, index.html, style.css, README.md, ainsi que votre .gitignore, doivent maintenant apparaître, avec le dernier message de commit affiché à côté de chacun. En cliquant sur l'onglet des commits du dépôt, vous devez retrouver exactement le même historique que celui affiché par git log --oneline sur votre machine.

C'est précisément ce moment que le premier guide de ce parcours annonçait : la différence entre un commit local et un commit visible en ligne. Avant ce push, vos quatre commits existaient, mais uniquement sur votre disque. Maintenant, ils existent aussi, à l'identique, sur les serveurs de GitHub.

Les prochains push seront plus courts

Grâce à l'option -u utilisée une seule fois, vos prochains envois pourront se limiter à :

Git saura automatiquement que « push » signifie « envoyer la branche main vers origin/main », sans que vous ayez besoin de le repréciser à chaque fois.

Bon réflexe

Avant chaque push, un git status puis un git log --oneline vous confirment exactement ce qui va partir. Après le push, retournez sur GitHub pour vérifier que le résultat affiché correspond à ce que vous attendiez : un commit local n'est jamais automatiquement synchronisé, ce contrôle prend quelques secondes et évite bien des doutes.

Un message d'erreur possible

Si votre dépôt GitHub n'était finalement pas complètement vide au moment du push, par exemple parce qu'une case d'initialisation a été cochée par erreur au guide précédent, Git peut refuser le push avec un message contenant « rejected » et « fetch first ». Cela signifie que le dépôt distant contient des commits que votre copie locale ne connaît pas encore. La solution n'est pas de forcer le push : elle consiste à récupérer d'abord ces commits distants, ce que vous apprendrez à faire dans le guide sur git fetch et git pull, un peu plus loin dans ce parcours.

Vérifiez que vous avez compris

Vous modifiez index.html, vous l'enregistrez dans votre éditeur, mais vous ne tapez ni git add ni git commit. Vous lancez directement git push. Cette modification sera-t-elle visible sur GitHub ensuite ?

Non. git push n'envoie que des commits déjà créés localement. Une modification simplement enregistrée sur le disque, sans être passée par git add puis git commit, n'existe pour Git dans aucun commit : il n'y a donc rien de nouveau à pousser, et GitHub ne verra aucun changement.

Chapitre terminé