git clone : cloner un dépôt GitHub (et d'ailleurs)

La commande git clone crée une copie locale complète d'un dépôt distant : fichiers, historique complet des commits, branches et tags. C'est la manière standard de commencer à travailler sur un projet déjà hébergé sur GitHub, GitLab ou un serveur d'entreprise. Contrairement au téléchargement d'une archive ZIP, un clone est un vrai dépôt dans lequel vous pouvez commiter et renvoyer vos modifications.

Utilisation de base de git clone

Copiez l'adresse du dépôt (sur GitHub, le bouton vert « Code ») et lancez :

git clone https://github.com/username/project.git

Cloning into 'project'...
remote: Enumerating objects: 1532, done.
remote: Counting objects: 100% (1532/1532), done.
remote: Compressing objects: 100% (812/812), done.
Receiving objects: 100% (1532/1532), 2.41 MiB | 6.10 MiB/s, done.
Resolving deltas: 100% (701/701), done.

Git crée un dossier project dans le répertoire courant (le nom est tiré de l'adresse, sans .git). Ensuite, placez-vous dedans :

cd project
git status

Ce que fait git clone en coulisses

Cloner, ce n'est pas simplement télécharger des fichiers. Comprendre ces étapes explique pourquoi tout « fonctionne tout seul » après un clone et d'où viennent les branches préfixées par origin/. Étape par étape, la commande :

1. crée le dossier et y exécute l'équivalent d'un git init ;
2. ajoute un remote nommé origin qui pointe vers l'adresse source ;
3. télécharge tous les objets et références — l'équivalent d'un git fetch ;
4. crée les branches distantes origin/main, origin/develop, etc. ;
5. crée la branche locale par défaut (généralement main), la lie à origin/main et extrait les fichiers.

C'est pourquoi il n'est pas nécessaire de configurer git remote à la main après un clone — git push et git pull fonctionnent immédiatement.

git remote -v
origin  https://github.com/username/project.git (fetch)
origin  https://github.com/username/project.git (push)

Cloner en HTTPS ou en SSH

Pour lire des projets publics d'autres personnes, HTTPS suffit. Pour vos propres dépôts, sur lesquels vous poussez régulièrement, SSH est plus pratique :

git clone git@github.com:username/project.git

Si vous avez déjà cloné en HTTPS et souhaitez passer en SSH, inutile de tout retélécharger :

git remote set-url origin git@github.com:username/project.git

Cloner dans un dossier précis

Le second argument est le nom ou le chemin du répertoire cible :

# Dans un dossier portant un autre nom
git clone https://github.com/username/project.git my-copy

# Dans le dossier courant (il doit être vide)
git clone https://github.com/username/project.git .

Si le dossier cible existe et n'est pas vide, Git refuse : fatal: destination path 'project' already exists and is not an empty directory.

Cloner une branche spécifique

Par défaut, après le clone, vous êtes sur la branche par défaut du dépôt distant. Pour arriver directement sur une autre, utilisez -b (--branch) :

git clone -b develop https://github.com/username/project.git

Attention : toutes les branches sont quand même téléchargées, vous vous retrouvez simplement sur develop. Si vous ne voulez qu'une seule branche, ajoutez --single-branch :

git clone -b develop --single-branch https://github.com/username/project.git

L'option -b accepte aussi un nom de tag — vous obtenez alors l'état du projet au moment de la release (en mode detached HEAD) :

git clone -b v2.1.0 --depth 1 https://github.com/username/project.git

Où sont les autres branches après le clone ?

Les débutants s'en étonnent : git branch n'affiche que main. Les autres branches ont été téléchargées en tant que branches distantes, et on les voit ainsi :

git branch -a

* main
  remotes/origin/HEAD -> origin/main
  remotes/origin/develop
  remotes/origin/feature/login

Pour travailler sur l'une d'elles, il suffit de s'y placer avec son nom court — Git crée automatiquement une branche locale qui suit la branche distante :

git switch develop

Clone superficiel : --depth pour les gros dépôts

Sur les vieux projets, l'historique peut peser des gigaoctets. Si vous n'avez besoin que du code actuel — par exemple en CI, ou simplement pour compiler le projet —, téléchargez uniquement les derniers commits :

git clone --depth 1 https://github.com/username/big-project.git

L'option --depth implique --single-branch : vous ne recevez donc que la branche par défaut et un seul commit. Si vous avez besoin plus tard de l'historique complet, vous pouvez le compléter :

git fetch --unshallow

On peut aussi indiquer une autre profondeur, par exemple --depth 50, ou limiter l'historique à une date avec --shallow-since=2025-01-01. Pour du développement actif, un clone superficiel est peu pratique : git log, git blame et la recherche dans l'historique seront incomplets.

Clone partiel : --filter

Pour les monorepos gigantesques, une alternative consiste à télécharger l'historique des commits mais à charger le contenu des fichiers à la demande :

git clone --filter=blob:none https://github.com/username/monorepo.git

Vous conservez ainsi l'historique complet pour log et pour changer de branche, tout en économisant bande passante et espace disque. Cela nécessite la prise en charge côté serveur ; GitHub et GitLab la proposent.

Clone miroir et migration d'un dépôt

Un clone classique récupère les branches en tant que branches distantes et ne copie pas les références techniques du serveur. Pour migrer un projet vers un autre hébergeur ou en faire une sauvegarde à l'identique, on utilise --mirror :

git clone --mirror https://github.com/username/project.git
cd project.git
git push --mirror git@gitlab.com:username/project.git

Un miroir est un dépôt bare, sans fichiers de travail, dans lequel toutes les branches et tous les tags sont stockés comme locaux. La commande git push --mirror les envoie en bloc sur le nouveau serveur, et l'historique est transféré sans perte. Notez que les issues, pull requests et paramètres de l'hébergeur ne sont pas migrés ainsi — ce sont des données du service, pas de Git.

L'option voisine --bare crée elle aussi un dépôt sans répertoire de travail, mais ne copie que les branches et les tags. Elle convient pour installer un dépôt central sur votre propre serveur à partir d'un projet existant.

Cloner avec les sous-modules

Si le projet utilise des git submodules, leurs dossiers seront vides par défaut. Pour tout télécharger d'un coup :

git clone --recurse-submodules https://github.com/username/project.git

Si vous avez déjà cloné sans cette option, récupérez les sous-modules :

git submodule update --init --recursive

git clone, fork ou téléchargement ZIP

Fork et clone ne s'opposent pas : pour contribuer à un projet open source, on fait d'abord un fork sur le site, puis on clone son propre fork et on ajoute l'original comme second remote :

git clone git@github.com:me/project.git
cd project
git remote add upstream https://github.com/author/project.git
git fetch upstream

Erreurs fréquentes avec git clone

« Repository not found »

Faute de frappe dans l'adresse, ou dépôt privé auquel vous n'avez pas accès. Pour les dépôts privés, GitHub répond volontairement « not found » plutôt que « accès refusé ». Vérifiez l'adresse et que vous êtes bien connecté avec le bon compte.

« Permission denied (publickey) »

Clone en SSH, mais la clé n'est pas configurée. Testez avec ssh -T git@github.com, ajoutez la clé publique dans les paramètres du compte ou clonez provisoirement en HTTPS.

« Authentication failed » en HTTPS

Vous avez saisi le mot de passe de votre compte. GitHub exige depuis longtemps un Personal Access Token à la place du mot de passe pour les opérations Git en HTTPS. Si Git a mémorisé de mauvais identifiants, supprimez-les dans le gestionnaire d'identifiants du système.

Interruption sur un gros dépôt

Les erreurs du type early EOF ou RPC failed sont souvent liées à un réseau instable et à la taille du dépôt. Un clone superficiel --depth 1 suivi d'un git fetch --unshallow, ou un clone en SSH, règle généralement le problème.

Problèmes de fins de ligne sous Windows

Après le clone, tous les fichiers apparaissent « modifiés » — c'est la conversion CRLF/LF qui se manifeste. Configurez git config --global core.autocrlf true sous Windows (ou input sous Linux et macOS), et de préférence définissez les règles dans le .gitattributes du projet.

Que faire juste après le clone

Le clone est prêt, mais avant de toucher au code, prenez quelques minutes pour vous préparer. Cela vous évitera les problèmes classiques dès le premier jour sur un projet qui n'est pas le vôtre.

1. Lisez le README et le CONTRIBUTING. On y trouve généralement comment installer les dépendances, lancer les tests et nommer les branches dans le projet.
2. Vérifiez la branche et l'état. git status et git log --oneline -5 vous montrent où vous êtes et quelles sont les dernières modifications.
3. Créez votre propre branche. Ne travaillez pas directement sur main : git switch -c feature/my-task.
4. Vérifiez l'auteur des commits. Si vous avez plusieurs comptes sur la machine (personnel et professionnel), définissez l'e-mail pour ce dépôt précis, sans --global : git config user.email "you@company.com".
5. Installez les dépendances. Les dossiers comme node_modules ou venv ne sont pas versionnés, on les crée en local : npm install, pip install -r requirements.txt, etc.

Garder son clone à jour

Le clonage ne se fait qu'une fois. Ensuite, les nouveaux commits de vos collègues se récupèrent depuis le même origin :

# Voir ce qui est arrivé sur le serveur, sans rien modifier
git fetch
git log --oneline main..origin/main

# Intégrer les modifications dans la branche courante
git pull

L'habitude de faire d'abord git fetch et de regarder ce qui est arrivé évite les conflits surprises. Inutile de recloner le projet « pour le mettre à jour » — on y perd les branches locales et le travail non commité.

Aide-mémoire git clone

En résumé

git clone télécharge le dépôt entier et configure immédiatement le lien avec le serveur via origin : vous pouvez ensuite commiter, faire des push et des pull sans configuration supplémentaire. Utilisez SSH pour vos propres projets, --depth ou --filter pour les gros dépôts, et -b pour la branche voulue. Le travail avec les dépôts distants, push, pull et fetch est mis en pratique dans le cours Git.