Objectifs

À la fin de cette leçon, vous saurez :

• situer le remote dans l'architecture Git (et démystifier GitHub) ;
• récupérer un projet existant avec clone ;
• publier votre travail avec push et rapatrier celui des autres avec pull ;
• comprendre et traiter correctement un refus de push.

🔗 Pour vous rafraîchir la mémoire : branches et fusion

Le remote : une copie pour partager

Souvenez-vous : votre dépôt local contient déjà TOUT — l'historique complet fonctionne sans connexion. Alors à quoi servent GitHub, GitLab ? À une seule chose : héberger une copie synchronisée de cet historique pour partager le travail.

votre machine                                        GitLab / GitHub
working dir → staging → dépôt local   ← push/pull →   dépôt distant

Deux flux seulement, dans les deux sens :

• push : envoie VOS nouveaux commits locaux vers la copie distante ;
• pull : ramène les commits distants que vous n'avez pas encore.

Point conceptuel essentiel : le dépôt distant n'est ni « la vraie version » ni un serveur dont vous dépendriez techniquement. C'est un pair parmi d'autres — vous pourriez synchroniser deux machines entre elles sans aucun hébergeur. Les plateformes ajoutent l'accessibilité permanente (une URL toujours allumée) et les outils autour (revues de code, MR/PR).

Récupérer un projet existant : clone

git clone https://gitlab.com/groupe/projet.git
cd projet
git log --oneline        # tout l'historique est déjà là

clone télécharge l'historique complet — tous les commits, branches incluses — et configure automatiquement le remote sous le nom canonique origin. Vérifions :

git remote -v
origin  https://gitlab.com/groupe/projet.git (fetch)
origin  https://gitlab.com/groupe/projet.git (push)

C'est le scénario « j'arrive sur un projet » : cloner, lire, travailler.

Ajouter un remote à un projet existant

Si votre dépôt local existait AVANT (comme carnet-de-bord du chapitre), on crée le dépôt vide côté plateforme puis on le déclare :

git remote add origin https://gitlab.com/vous/carnet-de-bord.git
git remote -v            # vérification, toujours

Le nom origin est une pure convention (« l'origine du projet ») ; tout autre nom fonctionnerait, mais ne déviez pas sans raison : tous les tutoriels du monde supposent origin.

Publier son travail : push

git push origin main

Lecture : « envoie mes commits locaux de main vers main chez origin ». Après succès :

Enumerating objects: 5, done.
...
To gitlab.com:vous/carnet-de-bord.git
 * [new branch]      main -> main

La copie distante et votre branche locale sont désormais identiques. Git suit cette correspondance via les branches de suivi : origin/main est votre miroir local de l'état distant — consultable comme une branche en lecture seule (git log --oneline origin/main). D'où les messages de git status que vous croiserez sans fin :

Your branch is ahead of 'origin/main' by 2 commits.
  (use "git push" to publish your local commits)

Traduction : deux de vos commits n'ont pas encore quitté votre machine. C'est l'état normal du travail en cours ; il devient un risque quand ça s'accumule pendant des jours.

Rapatrier le travail des autres : pull

Avant de commencer à travailler, et avant chaque push :

git pull origin main

Si d'autres ont poussé entre-temps, leurs commits arrivent et sont fusionnés dans les vôtres (avec éventuel conflit à résoudre — même protocole que la leçon précédente). Si personne n'a bougé :

Already up to date.

Pourquoi ce rythme ? Chaque pull réduit l'écart entre vous et les autres ; chaque push publié rend votre travail visible et sauvegardé ailleurs. La devise professionnelle tient en quatre mots : pull souvent, push tôt. Un développeur qui pousse une fois par semaine accumule des conflits monstres ; celui qui pousse par petites étapes cohérentes n'en voit presque jamais.

Le refus non-fast-forward : lecture et traitement

Scénario réel : votre collègue a poussé pendant votre travail. Vous tentez :

git push origin main

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to '...'
hint: Updates were rejected because the remote contains work that you do not have locally.

Lisez le message : le refus signifie « le distant contient du travail que tu n'as pas localement ». Si Git acceptait, il écraserait silencieusement le travail du collègue — il refuse donc, poliment mais fermement.

Réaction correcte, toujours la même séquence :

git pull origin main     # rapatrier + fusionner (conflit éventuel à résoudre)
# ...résoudre si besoin, committer la fusion...
git push origin main     # retenter : passe désormais

⚠️ Et le fameux --force ? Il dit à Git : « écrase le distant avec MA version, quoi qu'il y ait là-bas ». Sur une branche partagée, c'est la suppression pure et simple du travail des autres — à ne jamais faire sans comprendre exactement pourquoi (il existe des cas légitimes très précis, jamais avant le chapitre où ils auront du sens).

Exercice

1. Créez un dépôt vide sur GitLab (sans README initial) et notez son URL.
2. Depuis votre dépôt local carnet-de-bord, ajoutez-le comme remote (git remote add origin URL) et poussez main.
3. Vérifiez sur le site web : retrouvez vos fichiers ET votre historique complet.
4. Modifiez un fichier directement sur le site web (bouton « Edit »), puis faites git pull localement. Que s'est-il passé ?
5. Question de réflexion : votre connexion Internet tombe. Pouvez-vous continuer à commiter ? Que pourrez-vous faire quand elle reviendra ?

Résumé

• Remote = copie partagée de l'historique ; clone récupère tout, origin est son nom par défaut.
• origin/main = votre miroir local de l'état distant, alimenté par fetch/pull.
• pull avant push, souvent et tôt.
• Push refusé = le distant a avancé : pull, fusionner, re-pousser. Jamais de force sans raison maîtrisée.

Vérification locale :

git log --oneline origin/main # identique à git log --oneline

Sur le site : vos fichiers sont là, et la page historique montre vos commits avec leurs messages. Tout l'historique a voyagé — preuve supplémentaire que « le dépôt » est bien cette base complète, pas juste les fichiers visibles.

**Exercice 4.** Le `pull` télécharge un NOUVEAU commit — créé par l'interface web — et le fusionne dans votre historique local ; le fichier apparaît modifié chez vous. C'est exactement le scénario « quelqu'un d'autre a poussé », avec un enseignement déguisé : **le site web n'est qu'un contributeur de plus**. Une modification faite via l'interface vaut un commit comme un autre, et le workflow pull-push le gère sans distinction.

**Question 5.** Oui : tout le travail LOCAL reste possible — modifications, staging, commits, branches. Seuls push/pull nécessitent le réseau. Au retour de la connexion, un simple `git push` publiera tous les commits accumulés (Git listera même combien : « ahead by N »). C'est la conséquence directe de « Git est distribué » vu en début de chapitre : votre dépôt est autosuffisant ; le remote n'est qu'un point de partage.

git remote add origin https://gitlab.com/vous/carnet-de-bord.git
git push origin main