infra / git-github

Push vers GitHub : remote, clone, pull

Leçon 31 exercice

Explication

Ce que vous allez apprendre

Comprendre pourquoi Git est un outil local et ce qu'un "remote" ajoute par-dessus
Générer une clé SSH et l'ajouter à GitHub pour ne plus jamais retaper de mot de passe
Distinguer git fetch (télécharge) de git pull (télécharge et fusionne)
Lier un dépôt local à GitHub avec git remote add et pousser avec git push -u
Configurer pull.rebase pour garder un historique plus linéaire

Dans quel contexte ?

Un développeur vient de terminer une fonctionnalité en local sur le dépôt boutique-api, mais son ordinateur portable tombe en panne le lendemain. Sans avoir poussé son travail vers GitHub via git push, tout ce travail est perdu avec la machine. Cette leçon explique comment connecter un dépôt local à GitHub pour que le travail existe aussi ailleurs que sur un seul disque.

Un outil entièrement local, au départ

D'abord, tout ce que le cours a montré jusqu'ici se passait uniquement sur ta machine : Git est, à sa base, un outil entièrement local.

Ce qu'il faut pour collaborer

Pour collaborer avec d'autres personnes, ou simplement sauvegarder son travail en ligne, il faut un remote : un dépôt distant, hébergé par exemple sur GitHub, avec lequel ton dépôt local échange des commits.

La clé pour ne jamais être surpris

Comprendre que "local" et "distant" sont deux copies séparées, qui doivent être explicitement synchronisées, est la clé pour ne jamais être surpris par le comportement de Git.

S'authentifier une bonne fois pour toutes

Chaque échange avec GitHub nécessite de prouver qui tu es. Retaper un mot de passe à chaque push serait pénible et peu sûr.

La solution : une paire de clés

La clé SSH règle ce problème en une seule fois : une paire de clés est générée, une privée gardée secrète sur ta machine, une publique partagée avec GitHub. L'authentification se fait ensuite automatiquement et de façon chiffrée.

Une distinction que beaucoup de débutants confondent

Une fois connecté, il reste une distinction essentielle. git fetch télécharge les nouveaux commits du dépôt distant, mais ne touche à rien dans ton travail local.

Commande	Télécharge ?	Fusionne dans ta branche ?
`git fetch`	Oui	Non
`git pull`	Oui	Oui (merge par défaut)
`git pull --rebase`	Oui	Oui (rebase, historique linéaire)

Prérequis

Cette leçon suppose que tu es à l'aise avec les commits et l'historique local (leçon précédente) : le remote n'ajoute qu'une couche de synchronisation par-dessus ce que tu sais déjà faire.

Une opération bien plus engageante

git pull, lui, télécharge ET fusionne immédiatement ces changements dans ta branche actuelle. En cas de doute, fetch d'abord, inspecter, puis décider, est le réflexe le plus prudent.

Garder un historique propre

Un pull classique peut créer des commits de fusion un peu partout dans l'historique dès que toi et un collègue avez travaillé en parallèle.

Une option qui évite ce problème

L'option --rebase évite cela en rejouant tes commits locaux par-dessus les nouveaux commits distants, préservant un historique linéaire, un sujet détaillé dans la leçon dédiée au rebase.

Bonne pratique

Configure git config --global pull.rebase true dès l'installation de Git sur une nouvelle machine. Cela évite l'accumulation de commits de fusion "Merge branch main into main" qui n'apportent aucune information utile à l'historique du projet.

Maintenant que ton dépôt local communique avec GitHub, la leçon suivante s'attaque à un vrai besoin de collaboration : travailler sur plusieurs idées en parallèle avec les branches.

Commandes & code

Remote & push vers GitHub

# Générer une clé SSH et l'ajouter à GitHub (Settings > SSH and GPG keys)
ssh-keygen -t ed25519 -C "ada@example.com"
cat ~/.ssh/id_ed25519.pub
ssh -T git@github.com          # teste la connexion, doit répondre "Hi <user>!"

# Lier un dépôt local à GitHub
git remote add origin git@github.com:ada/mon-projet.git
git remote -v                          # liste les remotes (fetch + push)

# Premier push : "-u" mémorise le lien local/distant pour les push suivants
git push -u origin main
git push                                # une fois "-u" fait, plus besoin de préciser origin/main

# Récupérer les changements distants
git fetch origin              # télécharge SANS fusionner (regarder avant d'agir)
git log origin/main            # inspecter ce que contient la branche distante
git pull origin main            # équivaut à : git fetch + git merge origin/main

# Éviter les merge commits accidentels lors d'un pull
git pull --rebase origin main
git config --global pull.rebase true    # en faire le comportement par défaut

# Changer un remote existant (ex: migration HTTPS -> SSH)
git remote set-url origin git@github.com:ada/mon-projet.git
git remote remove upstream
git remote add upstream git@github.com:org/mon-projet.git   # dépôt original d'un fork

# Créer un dépôt sur GitHub directement en ligne de commande (via gh CLI)
gh repo create mon-projet --public --source=. --push
gh repo view --web

Résumé

SSH évite de retaper ses identifiants à chaque push (ssh-keygen + clé ajoutée sur GitHub).
git fetch télécharge sans modifier ; git pull télécharge ET fusionne (ou rebase).
pull.rebase = true garde un historique linéaire au lieu de multiplier les merge commits.
gh (GitHub CLI) permet de créer/gérer des dépôts sans quitter le terminal.

Exercices pratiques

1 disponible

Mission : sécuriser le travail avant la panne

Objectif : Distinguer fetch de pull pour éviter une fusion accidentelle, et corriger la configuration d'un remote mal renseigné.

Contexte

Sur boutique-api, le remote origin d'un développeur pointe encore vers une URL HTTPS alors que toute l'équipe est passée en SSH. Il hésite aussi entre fetch et pull après avoir vu des commits inattendus apparaître côté GitHub sur main.

Résoudre l’exercice →