Clone, pull et push

Cloner un dépôt existant

git clone récupère une copie complète d'un dépôt distant (GitHub, GitLab), avec tout son historique, sur la machine locale.

git clone https://github.com/organisation/projet.git

Rester synchronisé : git pull

Quand plusieurs personnes travaillent sur le même dépôt, git pull récupère les derniers changements distants et les intègre dans la copie locale.

git pull origin main

git pull combine en réalité deux opérations : git fetch (télécharger les changements sans les fusionner) suivi de git merge (les intégrer localement).

Envoyer ses changements : git push

git push origin nouvelle-fonctionnalite

Envoie les commits locaux vers le dépôt distant, sur la branche spécifiée.

Le rejet de push : quand quelqu'un vous a devancé

! [rejected] main -> main (fetch first)
error: failed to push some refs

Ce message signifie que le dépôt distant contient des commits que la copie locale n'a pas encore récupérés. Il faut git pull avant de pouvoir git push à nouveau, pour intégrer d'abord les changements distants.

Cas concret

Deux administrateurs système modifient le même dépôt de scripts d'automatisation. Le premier pousse ses changements sans problème. Le second, qui avait cloné le dépôt avant ces changements, tente de pousser les siens et reçoit un rejet : son historique local est "en retard" par rapport au distant. Un git pull récupère et fusionne les changements du premier, révélant éventuellement un conflit si les deux ont touché les mêmes lignes, avant que le second puisse pousser à son tour.

Erreurs fréquentes

• Forcer un push (git push --force) pour contourner un rejet sans comprendre pourquoi, ce qui peut écraser et perdre définitivement le travail d'un collègue poussé entre-temps.
• Ne jamais faire git pull avant de commencer à travailler en début de journée, travaillant sur une base potentiellement obsolète et augmentant le risque de conflits plus tard.
• Cloner un dépôt à chaque fois au lieu de simplement le mettre à jour avec git pull, perdant le travail local non encore poussé s'il existe.

À retenir

• git clone récupère une copie complète d'un dépôt distant, une seule fois en début de projet.
• git pull synchronise la copie locale avec les derniers changements distants avant de pouvoir pousser les siens.
• Un push rejeté signifie que le distant a évolué depuis le dernier pull local : jamais forcer sans comprendre pourquoi.

Mini-exercice

Un push est rejeté avec le message "fetch first". Que faut-il faire, et pourquoi ne jamais utiliser git push --force par réflexe dans ce cas ?

Réponse : faire un git pull pour récupérer et intégrer les changements distants manquants avant de retenter le push. Forcer le push écraserait ces changements distants sans les fusionner, risquant de perdre définitivement le travail poussé entre-temps par quelqu'un d'autre.