Jusqu'ici, vous avez toujours travaillé dans le même dossier mon-premier-site, créé au guide 4 avec git init. Mais il existe une seconde façon de démarrer un projet local : le récupérer depuis un dépôt distant déjà existant, avec git clone. C'est la méthode que vous utiliserez à chaque fois que vous rejoindrez un projet que vous n'avez pas créé vous-même.

Pourquoi ne pas juste télécharger un ZIP

GitHub propose un bouton pour télécharger n'importe quel dépôt sous forme d'archive ZIP. C'est utile si vous voulez seulement récupérer des fichiers, sans intention de contribuer. Mais cette archive ne contient que l'état actuel des fichiers, sans aucun historique : pas de commits, pas de branches, aucun lien vers le dépôt d'origine. git clone fait bien plus : il télécharge l'intégralité de l'historique Git, recrée toutes les branches connues, et configure automatiquement un remote nommé origin pointant vers l'adresse clonée.

Cloner mon-premier-site dans un nouveau dossier

Pour cette pratique, choisissez un emplacement différent de celui de votre dossier actuel, par exemple un nouveau dossier mon-premier-site-clone dans vos Documents. Cela simule ce qui se passerait sur un second ordinateur, sans risquer d'interférer avec votre travail existant.

Le nom donné après l'URL, ici mon-premier-site-clone, indique à Git le nom du dossier à créer. Vous pouvez l'omettre : Git utilise alors par défaut le nom du dépôt tel qu'il apparaît dans l'URL. Sur un vrai second ordinateur, vous n'auriez évidemment pas besoin de renommer le dossier ainsi ; cette précaution ne sert ici qu'à éviter un conflit de nom avec votre dossier de travail habituel.

Entrer dans le dossier cloné

Git ne vous place pas automatiquement dans le nouveau dossier après un clone : c'est à vous de vous y déplacer avant de continuer.

Tous vos fichiers sont là, dans leur dernière version poussée sur GitHub. Sous macOS ou Linux, remplacez dir par ls.

Vérifier que l'historique complet est bien présent

Vous retrouvez exactement le même historique que dans votre dossier original, avec les mêmes identifiants de commit. Ce n'est pas une coïncidence : un clone récupère l'historique réel, pas une reconstruction approximative.

Vérifiez aussi le remote, configuré automatiquement cette fois, sans que vous ayez tapé git remote add vous-même.

Un clone configure toujours origin automatiquement vers l'adresse utilisée pour le cloner. C'est une différence pratique avec le guide 13, où vous aviez dû taper cette configuration vous-même sur un dépôt local préexistant.

Deux dossiers, un seul historique partagé

Vous avez maintenant deux dossiers sur votre ordinateur, mon-premier-site et mon-premier-site-clone, tous deux reliés au même dépôt GitHub. Un commit poussé depuis l'un ne sera visible dans l'autre qu'après une synchronisation explicite, avec les commandes que vous découvrirez au prochain guide.

Erreur fréquente au clonage

Si Git répond « fatal: destination path 'mon-premier-site-clone' already exists and is not an empty directory », c'est qu'un dossier de ce nom existe déjà à cet endroit et contient des fichiers. Choisissez un autre nom de dossier, ou supprimez ce dossier si vous êtes certain qu'il ne contient rien d'important.

Vérifiez que vous avez compris

Depuis mon-premier-site-clone, vous modifiez index.html et créez un commit local, sans le pousser. Ce nouveau commit apparaît-il automatiquement dans votre dossier original mon-premier-site ?

Non. Bien que les deux dossiers partagent le même historique au moment du clone, ce sont ensuite deux copies locales totalement indépendantes. Un commit créé dans l'une ne rejoint l'autre qu'en passant explicitement par GitHub : un push depuis la première, puis un pull ou un fetch depuis la seconde.

Chapitre terminé