Le message que vous allez rencontrer
Vous avez travaillé, enregistré, et vous publiez. Et là :
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://forge.nordika.local/...'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref.
Rien n’est cassé. Git vous dit simplement : le serveur a avancé pendant que vous travailliez. Un collègue a publié quelque chose que vous n’avez pas.
Git refuse de publier par-dessus, parce que cela écraserait le travail de l’autre. C’est une protection, et c’est exactement le comportement que vous voulez.
La solution tient en trois commandes — mais autant comprendre ce qu’elles font, parce que c’est ici que se joue la moitié des incompréhensions autour de Git.
fetch et pull : la distinction fondamentale
git fetch # « va voir ce qu'il y a de neuf, sans rien toucher chez moi »
git pull # « va voir, ET intègre chez moi »
git pull fait deux choses en une : fetch puis merge. C’est ce cumul qui déroute, parce qu’on ne sait plus laquelle des deux a produit le résultat qu’on observe.
Voici ce qui se passe, étape par étape.
git fetch — se renseigner
AVANT APRÈS git fetch
main a3f9c21 main a3f9c21 ← inchangé
origin/main a3f9c21 origin/main 7d2e881 ← mis à jour
Souvenez-vous de la leçon 3.2 : origin/main est votre dernière connaissance de la branche du serveur. fetch met à jour cette connaissance.