« Et si mon ordinateur tombe en panne ? »
Jusqu'ici, tout votre historique Git vit sur votre machine, dans le dossier .git. C'est génial... tant que votre disque dur fonctionne. Le jour où il rend l'âme, ou le jour où vous voulez travailler depuis un autre ordinateur, ou simplement partager votre projet avec un collègue, vous avez besoin d'un endroit central et accessible.
C'est le rôle du dépôt distant : une copie de votre dépôt hébergée sur un serveur, à laquelle tout le monde se synchronise. GitHub est le service le plus connu pour héberger ces dépôts distants.
Local et distant : deux copies synchronisées
Il faut bien distinguer deux choses :
- Le dépôt local — sur votre machine. C'est là que vous committez, créez des branches, expérimentez. Tout fonctionne même sans connexion internet.
- Le dépôt distant — sur GitHub (ou GitLab). C'est la copie de référence, partagée, que l'équipe utilise pour se synchroniser.
Ces deux copies ne se synchronisent pas toutes seules. Vous décidez quand envoyer vos commits vers le distant, et quand récupérer ceux des autres. Rien n'est automatique : vous gardez le contrôle.
git push envoie vos commits vers GitHub ; git pull récupère ceux des autres. Vous gardez le contrôle du moment.Le modèle push / pull. git push envoie vos commits locaux vers le distant. git pull récupère les commits du distant et les intègre chez vous. Pensez-y comme une boîte aux lettres partagée : vous y déposez votre courrier (push) et vous relevez celui des autres (pull).
Cloner, pousser, tirer
Le cycle de travail avec un dépôt distant :
# Récupérer un projet existant depuis GitHub
$ git clone https://github.com/alice/mon-site.git
Cloning into 'mon-site'...
remote: Enumerating objects: 42, done.
Receiving objects: 100% (42/42), done.
$ cd mon-site
$ git remote -v
origin https://github.com/alice/mon-site.git (fetch)
origin https://github.com/alice/mon-site.git (push)
# Après avoir committé en local, envoyer vers le distant
$ git push origin main
Enumerating objects: 5, done.
To https://github.com/alice/mon-site.git
c3d4e5f..a1b2c3d main -> main
# Récupérer le travail des autres
$ git pull origin main
Already up to date.git clone télécharge un dépôt entier avec tout son historique. git remote -v liste les distants connus (le distant par défaut s'appelle origin). git push envoie, git pull récupère. Il existe aussi git fetch, qui récupère les changements distants sans les fusionner tout de suite : pratique pour regarder avant d'intégrer.
GitHub, plus qu'un hébergeur : les pull requests
GitHub n'est pas qu'un disque dur en ligne. C'est une plateforme de collaboration. Sa pièce maîtresse : la pull request (PR).
Le principe : au lieu de fusionner directement votre branche dans main, vous ouvrez une pull request. C'est une demande de fusion accompagnée d'une discussion. Vos collègues relisent le code, commentent ligne par ligne, suggèrent des corrections. Une fois validée, la PR est fusionnée dans main.
C'est le cœur du travail en équipe moderne : rien n'entre dans la branche principale sans avoir été relu. La qualité du code y gagne énormément, et c'est aussi un formidable outil d'apprentissage quand on débute.
"What if my computer dies?"
So far, your entire Git history lives on your machine, in the .git folder. That is great... as long as your hard drive works. The day it dies, or the day you want to work from another computer, or simply share your project with a colleague, you need a central, accessible place.
That is the role of the remote repository: a copy of your repository hosted on a server, that everyone syncs to. GitHub is the best-known service for hosting these remote repositories.
Local and remote: two synced copies
You need to clearly distinguish two things:
- The local repository — on your machine. This is where you commit, create branches, experiment. Everything works even without an internet connection.
- The remote repository — on GitHub (or GitLab). It is the shared reference copy the team uses to sync.
These two copies do not sync on their own. You decide when to send your commits to the remote, and when to fetch others'. Nothing is automatic: you keep control.
git push sends your commits to GitHub; git pull fetches others'. You stay in control of when.The push / pull model. git push sends your local commits to the remote. git pull retrieves the remote commits and integrates them on your side. Think of it as a shared mailbox: you drop off your mail (push) and you collect others' (pull).
Clone, push, pull
The working cycle with a remote repository:
# Get an existing project from GitHub
$ git clone https://github.com/alice/my-site.git
Cloning into 'my-site'...
remote: Enumerating objects: 42, done.
Receiving objects: 100% (42/42), done.
$ cd my-site
$ git remote -v
origin https://github.com/alice/my-site.git (fetch)
origin https://github.com/alice/my-site.git (push)
# After committing locally, send to the remote
$ git push origin main
Enumerating objects: 5, done.
To https://github.com/alice/my-site.git
c3d4e5f..a1b2c3d main -> main
# Get others' work
$ git pull origin main
Already up to date.git clone downloads an entire repository with all its history. git remote -v lists the known remotes (the default remote is called origin). git push sends, git pull retrieves. There is also git fetch, which retrieves remote changes without merging them right away: handy to look before integrating.
GitHub, more than a host: pull requests
GitHub is not just an online hard drive. It is a collaboration platform. Its centerpiece: the pull request (PR).
The principle: instead of merging your branch directly into main, you open a pull request. It is a merge request accompanied by a discussion. Your colleagues review the code, comment line by line, suggest fixes. Once approved, the PR is merged into main.
This is the heart of modern teamwork: nothing enters the main branch without being reviewed. Code quality gains enormously, and it is also a fantastic learning tool when you are starting out.
Un push refusé ? Collez le message d'erreur exact à l'IA pour comprendre et corriger :
Je débute avec Git et GitHub. Mon git push origin main est refusé avec ce message : ! [rejected] main -> main (fetch first). error: failed to push some refs. Explique-moi en français pourquoi ce refus arrive, ce que ça veut dire concrètement, et donne-moi étape par étape les commandes pour résoudre la situation sans perdre mon travail.
Sans relire la réponse de l'IA : avec tes mots, pourquoi un git push est-il refusé avec (fetch first), et que fais-tu pour le débloquer sans perdre ton travail ?
(fetch first). La solution sûre : git pull origin main (ou git fetch puis intégrer) pour récupérer et fusionner les commits distants, résoudre un éventuel conflit, puis git push origin main. Surtout pas de git push --force qui écraserait le travail des autres.Écrivez les commandes pour : cloner un dépôt depuis GitHub, récupérer les derniers changements du distant, puis envoyer vos commits locaux. Utilisez git clone, git pull et git push.
Ton push sur la branche partagée main est refusé. L'IA te propose ces commandes pour t'en sortir. Ton rôle de relecteur : les accepter ou les rejeter, et dire pourquoi.
# L'IA propose :
$ git push --force origin main--force écrase l'historique distant et supprime les commits qu'un collègue a poussés entre-temps : leur travail disparaît, sans avertissement. C'est exactement le scénario que le refus (fetch first) voulait t'éviter. Le bon réflexe : git pull origin main pour récupérer et fusionner d'abord, résoudre un éventuel conflit, puis git push origin main normalement. On ne force jamais un push sur une branche partagée.Sans remonter dans la leçon : dans quel sens vont git push et git pull entre le dépôt local et le distant, et comment s'appelle le distant par défaut ?
git push envoie tes commits locaux vers le distant ; git pull récupère les commits du distant et les intègre en local (c'est un git fetch suivi d'une fusion). Le distant par défaut, celui créé par git clone, s'appelle origin.Your code is safe on GitHub, synced between local and remote. One thing still triggers panic in everyone: the CONFLICT message when two versions clash. The last lesson teaches you to read conflict markers, resolve them calmly, and adopt good practices with .gitignore.
Lesson 7: Conflicts and best practices →