Un git clone crée une copie de travail et ajoute généralement le dépôt distant sous le nom origin. Le piège arrive avant la première commande : une URL SSH utilise votre clé, une URL HTTPS demande souvent un jeton, et le dossier cible ne doit pas déjà contenir des fichiers utiles. Prenez deux minutes pour vérifier ces trois points avant de lancer un script récupéré en ligne.
Choisir HTTPS ou SSH avant de cloner
Utilisez HTTPS pour récupérer un projet public ou quand vous ne voulez pas configurer de clé sur cette machine. Pour pousser ensuite vers GitHub, GitLab ou votre forge, le mot de passe du compte ne suffit généralement plus : le service demande un jeton d’accès personnel.
Utilisez SSH si votre clé publique est déjà associée à votre compte sur la forge. Cette méthode évite de retaper un jeton, mais elle échoue si la mauvaise clé est proposée ou si l’agent SSH ne la charge pas. Commencez par lire l’identité utilisée :
ssh -T [email protected]
ssh-add -lAdaptez le premier hôte à votre forge. Une réponse d’authentification sans shell distant est normale chez plusieurs hébergeurs Git. Si vous gérez plusieurs clés, contrôlez votre fichier ~/.ssh/config avec ssh -G [email protected] avant d’accuser Git. Notre guide pour configurer SSH pour plusieurs serveurs explique comment fixer une clé et un compte par alias.
Créer la copie dans un dossier vide et identifiable
Placez-vous dans un répertoire réservé à vos projets. Sans second argument, Git crée un dossier à partir du nom du dépôt. Avec un nom explicite, vous évitez de confondre une copie de test avec celle qui contient vos modifications.
mkdir -p ~/projets
cd ~/projets
pwd
ls -la
git clone https://github.com/octocat/Hello-World.git hello-test
cd hello-testNe lancez pas un clone dans un dossier dont vous ne connaissez pas le contenu. Git refuse en général un répertoire non vide, mais il reste plus sûr de vérifier pwd et ls -la avant la commande. Pour une copie destinée seulement à lire le code, HTTPS reste le choix le plus simple.
Avec SSH, la même opération ressemble à ceci :
git clone [email protected]:mon-compte/mon-projet.git mon-projet
cd mon-projetRemplacez l’hôte, le compte et le dépôt par les valeurs affichées par votre forge. Ne copiez jamais une URL reçue dans un message douteux. Ouvrez d’abord la page officielle du projet et comparez le propriétaire, le nom du dépôt et l’URL de clonage.
Contrôler le remote et les fichiers avant d’exécuter quoi que ce soit
Après le clone, vérifiez l’origine, la branche active et l’état du répertoire. Ces commandes ne modifient pas le projet :
git remote -v
git branch --show-current
git status
git log -1 --oneline
find . -maxdepth 2 -type f -name 'README*' -o -name 'INSTALL*'git remote -v affiche les URLs utilisées pour récupérer et envoyer les changements. Vérifiez-les avant un premier git push, surtout si le projet contient une configuration de déploiement. Lisez ensuite le README, les fichiers INSTALL, les dépendances et les scripts de démarrage. Un dépôt Git peut contenir un script valide, ancien ou franchement risqué, il n’acquiert pas votre confiance parce que le clone a réussi.
Pour récupérer une mise à jour plus tard, restez dans le dossier cloné et commencez par contrôler votre travail :
git status
git fetch origin
git log --oneline HEAD..origin/$(git branch --show-current)
git pull --ff-onlygit pull --ff-only refuse une fusion automatique si vos commits locaux et le dépôt distant divergent. C’est préférable à une mise à jour qui mélange des changements alors que vous n’avez pas encore regardé la branche ni le remote.
La documentation officielle de git clone détaille les options comme --depth, --branch et --recurse-submodules. Gardez-les pour un besoin identifié. Pour un premier clone, une URL vérifiée, un dossier propre et la lecture du README évitent déjà la plupart des erreurs.