Premiers pas avec Git : initialisation et clonage de dépôts

L'initialisation et le clonage de dépôts sont les deux manières de base pour commencer à travailler avec Git. Soit vous transformez un dossier existant en dépôt Git, soit vous copiez un dépôt existant pour pouvoir travailler avec ses fichiers et son historique.

Ces commandes semblent simples, mais les choix que vous faites au début affectent les dépôts distants, les branches, les fichiers ignorés et les flux de travail d'équipe. Une configuration propre évite les confusions ultérieures.

Ce que contient un dépôt Git

Un dépôt Git est un dossier de projet contenant un répertoire caché .git à l'intérieur. Ce répertoire .git stocke l'historique des commits, les références de branches, les informations sur les dépôts distants, la configuration et la base de données interne des objets de Git.

Normalement, vous ne modifiez pas les fichiers .git à la main. Vous utilisez les commandes Git, et Git met à jour ces données internes pour vous.

Pour vérifier si un dossier est déjà un dépôt, exécutez :

git status

Si Git indique que le dossier n'est pas un dépôt, vous pouvez en initialiser un. S'il affiche une branche, des fichiers modifiés ou un arbre de travail propre, Git suit déjà ce dossier.

Il est utile de comprendre trois zones courantes :

Arbre de travail : les fichiers que vous pouvez voir et modifier.
Zone de staging : les modifications sélectionnées pour le prochain commit.
Historique du dépôt : les commits que Git a déjà enregistrés.

Lorsque vous initialisez ou clonez un dépôt, Git met en place ces éléments pour que vous puissiez commencer à faire des commits.

Initialiser un nouveau dépôt

Utilisez git init lorsque vous avez un dossier de projet local qui n'est pas encore suivi par Git.

Créez un dossier et initialisez-le :

mkdir my-app
cd my-app
git init

Git crée le répertoire caché .git. Vous pouvez maintenant ajouter des fichiers et faire votre premier commit :

echo "# My App" > README.md
git add README.md
git commit -m "Ajout du README"

Si votre branche par défaut doit être nommée main, vous pouvez la définir globalement avant de créer de nouveaux dépôts :

git config --global init.defaultBranch main

Ou renommer la branche actuelle après initialisation :

git branch -M main

Pour un projet réel, créez un .gitignore avant votre premier commit large. Cela empêche les dossiers de dépendances, les sorties de build, les logs et les secrets locaux d'entrer dans l'historique :

node_modules/
dist/
.env
*.log

Une fois qu'un fichier est commité, l'ajouter à .gitignore plus tard ne le retire pas de l'historique. C'est pourquoi les règles d'ignorance précoces sont importantes.

Si vous prévoyez de publier le dépôt sur un service d'hébergement, créez d'abord le dépôt distant vide là-bas, puis connectez-le :

git remote add origin [email protected]:exemple/my-app.git
git push -u origin main

L'option -u définit le suivi amont. Après cela, les simples git push et git pull savent quelle branche distante utiliser.

Cloner un dépôt existant

Utilisez git clone lorsqu'un dépôt existe déjà ailleurs. Le clonage copie les fichiers du projet, l'historique et la configuration distante.

La commande de base est :

git clone [email protected]:exemple/my-app.git

Git crée un dossier nommé d'après le dépôt. Pour choisir un nom de dossier local différent, ajoutez-le à la fin :

git clone [email protected]:exemple/my-app.git worktree-app

Après le clonage, déplacez-vous dans le dossier et inspectez-le :

cd worktree-app
git status
git remote -v
git branch

Par défaut, le dépôt distant est généralement nommé origin. Ce nom est conventionnel, pas magique. Il pointe vers l'URL que Git utilisera pour les fetchs et les pushes.

Vous pouvez voir des URL de clone HTTPS ou SSH. HTTPS est facile à utiliser, surtout pour les dépôts publics. SSH est courant pour le développement quotidien car il utilise des clés et évite les invites de mot de passe répétées lorsqu'il est configuré correctement.

Pour un grand dépôt, vous pouvez utiliser un clone peu profond :

git clone --depth 1 https://exemple.com/repo.git

Cela télécharge uniquement l'historique récent. C'est utile pour les tâches CI ou une inspection rapide, mais cela peut limiter les commandes qui nécessitent des commits plus anciens, des tags ou tout l'historique. Pour un développement normal, un clone complet est généralement préférable.

Si le dépôt utilise des sous-modules, clonez avec :

git clone --recurse-submodules [email protected]:exemple/platform.git

Ou initialisez-les après le clonage :

git submodule update --init --recursive

Les sous-modules ajoutent une autre couche de gestion de dépôt, alors lisez la documentation de configuration du projet avant d'apporter des modifications.

Premières vérifications courantes après la configuration

Après avoir initialisé ou cloné, effectuez quelques vérifications avant de commencer à coder. Elles aident à détecter une mauvaise configuration tôt.

Vérifiez votre identité :

git config user.name
git config user.email

S'il s'agit d'un dépôt professionnel, assurez-vous que l'email correspond à votre compte d'entreprise. Vous pouvez le définir localement :

git config --local user.email "[email protected]"

Vérifiez les dépôts distants :

git remote -v

Assurez-vous que les URL de fetch et de push pointent vers le dépôt attendu. Pousser accidentellement vers un fork ou un miroir personnel peut faire perdre du temps.

Vérifiez la branche actuelle :

git branch --show-current

Si vous avez cloné un dépôt, lisez le README ou le guide de contribution avant de créer une branche. De nombreuses équipes s'attendent à des noms de branche comme feature/ticket-123-courte-description ou fix/login-timeout.

Avant votre premier commit, vérifiez les fichiers ignorés :

git status --ignored

C'est un moyen rapide de confirmer que les artefacts de build et les fichiers secrets locaux ne sont pas sur le point d'être commités.

Quand demander de l'aide

Demandez de l'aide à un coéquipier ou au responsable du dépôt si vous n'êtes pas sûr de l'URL distante à utiliser, si vous devez cloner un fork ou le dépôt principal, ou comment les sous-modules doivent être gérés.

Vous devriez également faire une pause si vous avez initialisé Git dans le mauvais répertoire. Par exemple, exécuter git init dans votre dossier personnel peut amener Git à voir des milliers de fichiers non liés. Ne commencez pas à supprimer des choses au hasard. Confirmez où .git a été créé et supprimez uniquement les métadonnées de dépôt erronées si vous êtes sûr qu'elles ne contiennent aucun historique nécessaire.

Commencer avec Git repose principalement sur de bonnes habitudes. Utilisez git init pour les nouveaux projets locaux, git clone pour les dépôts existants, et vérifiez votre branche, votre dépôt distant, votre identité et les fichiers ignorés avant de commencer un travail sérieux.