Commande Git Clone : De l'utilisation de base aux techniques avancées

URL et protocoles Git

Comme le montre l'exemple ci-dessus de clonage du référentiel « aws-cli », pour cloner un référentiel à l'aide d'git clone, il est nécessaire de fournir l'emplacement du référentiel distant, ce qui se fait via une URL Git.

Git prend en charge plusieurs protocoles pour accéder à des référentiels distants, chacun avec sa propre structure, son modèle de sécurité et ses cas d'utilisation optimaux. Comprendre les différents types d'URL Git et savoir quand les utiliser peut vous aider à travailler de manière plus sécurisée et plus efficace, en particulier lorsque vous collaborez avec plusieurs équipes ou que vous automatisez des déploiements.

Types d'URL Git

Lors du clonage d'un dépôt, l'URL que vous fournissez indique à Git comment se connecter au serveur distant. Les types d'URL Git les plus courants sont les suivants :

HTTPS

Protocole de transfert hypertexte sécurisé (HTTPS). Principalement utilisé pour accéder à des pages Web via un navigateur Web. Ce type d'URL est simple à utiliser et ne nécessite aucune configuration lors du clonage d'un dépôt public. Voici quelques exemples :

git clone https://github.com/<username>/<repo>.git
git clone https://github.com/aws/aws-cli.git
git clone https://gitlab.com/gitlab-org/gitlab.git

Décomposition de la structure :

• https:// – Protocole utilisé pour la communication (sécurisé et compatible avec les pare-feu).
• github.com – Domaine du service d'hébergement Git.
• username/repo.git – Chemin d'accès au référentiel :
• username est le propriétaire (utilisateur ou organisation)
• repo.git est le nom du dépôt Git.

SSH

Secure Shell (SSH). Protocole réseau authentifié qui exige que vous fournissiez vos informations d'identification au serveur hôte avant de vous connecter. Nécessite la génération d'une paire de clés SSH et l'ajout de la clé publique à votre fournisseur Git (par exemple, GitHub, GitLab).

git clone git@github.com:<username>/<repo>.git
git clone git@github.com:aws/aws-cli.git
git clone git@gitlab.com:gitlab-org/gitlab.git

Décomposition de la structure :

• git@ – Spécifie le compte utilisateur SSH (généralement git).
• github.com: – Domaine du serveur Git, suivi d'un deux-points : (et non d'une barre oblique).
• username/repo.git – Chemin d'accès au référentiel sur le serveur.

Comme je n'ai configuré aucune clé SSH sur mon compte GitHub, le message suivant s'affiche lorsque j'essaie de copier l'URL SSH.

Aucune clé SSH configurée

Je vais vous expliquer comment configurer les clés SSH dans la section suivante.

GIT

Protocole léger et non authentifié pour un accès en lecture seule. Il s'agit d'un protocole propre à Git. Il est rarement utilisé de nos jours en raison de problèmes de sécurité et de sa dépréciation par les principaux fournisseurs tels que GitHub et GitLab. Vous ne trouverez même pas l'option permettant de cloner à l'aide du protocole git sur GitHub ou GitLab.

# Not recommended
git clone git://github.com/<username>/<repo>.git

Décomposition de la structure :

• git// – Protocole Git (lecture seule, non authentifié).
• github.com: – Domaine du serveur Git.
• username/repo.git – Chemin d'accès au référentiel sur le serveur.

Quel que soit le protocole de clonage utilisé, vous pouvez vérifier l'URL et le protocole utilisés en exécutant les commandes suivantes :

git remote -v
git remote show origin

Choisir le protocole URL approprié

Chaque protocole présente des avantages et des inconvénients. À l'aide du tableau suivant, nous comparons les avantages et les inconvénients liés au choix du protocole adapté à votre cas d'utilisation.

Procédures de clonage spécifiques au protocole

Une fois que vous avez sélectionné un protocole URL Git, le processus de clonage et la procédure d'authentification diffèrent. Bien que ces deux méthodes permettent d'atteindre le même objectif (cloner un dépôt distant sur votre machine locale), elles répondent à des préférences de sécurité, des besoins des utilisateurs et des complexités de configuration différents. 

Dans cette section, nous aborderons le clonage d'un référentiel à l'aide de HTTPS et SSH, ainsi que les meilleures pratiques, les étapes de configuration et les conseils de dépannage pour garantir un processus de clonage sécurisé et fluide.

Workflow de clonage Git HTTPS

Le clonage d'un dépôt Git via HTTPS est la méthode la plus simple, ce qui la rend idéale pour les débutants et les environnements contraints (tels que les pare-feu d'entreprise ou les réseaux restreints).

Pour cloner un référentiel, accédez-y et copiez l'URL HTTPS. L'image suivante est extraite de GitHub. Cela sera similaire à votre fournisseur Git.

Obtenir l'URL HTTPS d'un référentiel sur GitHub

Ensuite, exécutez la commande « git clone » sur la destination (par exemple, votre ordinateur portable ou un pipeline CI/CD) où vous souhaitez cloner le référentiel.

git clone https://github.com/aws/aws-cli.git

Commande git clone de base

Pour cloner un référentiel public, comme nous l'avons fait pour le référentiel « aws-cli », aucune authentification n'est requise, car le référentiel est public. Tant que vous avez installé git sur votre système, vous pouvez cloner immédiatement le dépôt public sans aucune configuration.

Toutefois, si vous clonez un dépôt privé, une authentification est requise. Vous pouvez vous authentifier via :

• Jeton d'accès personnel
• Clés universelles

Pour démontrer l'authentification via un jeton d'accès personnel, j'ai lancé un serveur dans AWS EC2 et installé Git. Lors de l'exécution de la commande « git clone » sur un référentiel privé, un nom d'utilisateur et un mot de passe sont demandés. Veuillez saisir votre nom d'utilisateur GitHub comme nom d'utilisateur et votre jeton d'accès personnel comme mot de passe.

Authentification HTTPS par nom d'utilisateur/mot de passe

En raison du renforcement des politiques de sécurité, GitHub et d'autres fournisseurs exigent désormais un jeton d'accès personnel au lieu d'un mot de passe.

Clonage avec les instructions relatives au jeton d'accès aux URL HTTPS. Source : GitHub

Si vous n'entrez pas votre jeton d'accès personnel, l'erreur suivante s'affichera :

La prise en charge de l'authentification par mot de passe a été supprimée.

Pour créer unjeton d'accès personnel, accédez à Créer un jeton GitHub et suivez les instructions : 

Veuillez créer un jeton d'accès personnel sur GitHub.

Pour éviter d'avoir à saisir votre jeton d'accès personnel à chaque fois que Git demande une authentification via HTTPS, vous pouvez utiliser un assistant d'informations d'identification pour mettre en cache vos informations d'identification en toute sécurité. Une option populaire est le gestionnaire d'informations d'identification Git. 

Sur macOS, Git s'intègre parfaitement au trousseau macOS, que j'utilise personnellement pour stocker mes identifiants. Dans mon cas, je m'authentifie à l'aide de clés d'accès stockées dans le trousseau, ce qui me garantit une expérience sécurisée et fluide.

Afficher l'assistant d'informations d'identification

Clés d'accès sur MacOS

Pour configurer une clé d'accès, accédez aux paramètres de mot de passe et d'authentification de GitHubetsuivez les instructions.

Créer une clé d'accès sur GitHub

Bien que GitHub vous permette de créer un jeton d'accès personnel sans date d'expiration, la plupart des organisations appliquent des politiques de sécurité qui exigent que les jetons aient une date d'expiration. Cela signifie que si un jeton est utilisé dans des environnements automatisés, tels que des pipelines CI/CD, et qu'il expire, le pipeline échouera en raison d'erreurs d'authentification. Il est essentiel de régénérer le jeton de manière proactive avant son expiration et de mettre à jour son utilisation en conséquence.

Sans contrôles appropriés, les développeurs peuvent involontairement créer et utiliser plusieurs jetons d'accès personnels sans documentation claire ni suivi. Cela peut rapidement entraîner une confusion quant au jeton utilisé et à son emplacement, ce qui complique la maintenance et l'audit. Pour une meilleure hygiène, il est recommandé de limiter l'utilisation des jetons, de la documenter et de la lier à des cas d'utilisation spécifiques.

Méthodologie de clonage SSH

SSH offre une méthode d'authentification sécurisée et persistante, particulièrement adaptée aux contributeurs réguliers et aux utilisateurs avancés. Une fois configuré, il offre un moyen transparent d'interagir avec les référentiels sans avoir à saisir à plusieurs reprises vos identifiants.

Pour configurer l'authentification SSH, il est nécessaire de générer une paire de clés SSH, composée d'une clé publique et d'une clé privée.

# ed25519 specifies the key type
ssh-keygen -t ed25519 -C "your_email@google.com"

Créer une paire de clés SSH

Comme je dispose déjà d'une clé SSH dans ~/.ssh/id_ed25519, j'ai remplacé le répertoire par défaut où les clés seront stockées. Toutefois, si vous créez la clé SSH pour la première fois sur votre appareil, veuillez accepter le répertoire par défaut.

Veuillez vous rendre dans les clés SSH et GPC sur GitHub pour configurer votre clé SSH.

Configurer une clé SSH sur GitHub

Veuillez copier le contenu de la clé publique dans la section « Clé ». Dans mon cas, il s'agit du contenu du fichier id_ed25519.pub.

Veuillez coller le contenu de id_ed25519.pub

SSH utilise un système de chiffrement à clé publique/privée. Veuillez conserver votre clé privée en lieu sûr sur votre ordinateur. Vous êtes maintenant prêt à cloner un dépôt, qu'il soit public ou privé, via SSH.

Une fois SSH configuré avec succès, la sélection de l'URL SSH n'affiche plus le message d'avertissement, comme indiqué dans la section « Types d'URL Git » ci-dessus.

Obtenir l'URL SSH d'un référentiel sur GitHub

Étant donné que la clé privée SSH se trouve sur mon appareil local, je vais vous montrer comment procéder à l' git clone ation à l'aide de SSH sur mon appareil local plutôt que sur le serveur EC2.

git clone git@github.com:aws/aws-cli.git

Cloner des référentiels publics et privés à l'aide de SSH

Nous avons effectué avec succès l'opération git clone à l'aide de SSH.

Les avantages du protocole SSH incluent sa sécurité et son utilisation répandue dans les organisations, car il permet une authentification sans mot de passe, ce qui est idéal pour les interactions fréquentes. Les connexions SSH sont également résistantes aux interruptions réseau et sont souvent plus rapides que le protocole HTTPS sur de longues distances.

Cependant, les développeurs rencontrent souvent des problèmes lors de la configuration de la clé SSH, car ils copient la mauvaise clé publique vers le fournisseur Git. Si vous disposez de plusieurs clés privées à des fins différentes, vous devez définir dans le fichier ~/.ssh/config quelle clé utiliser pour chaque hôte. Dans le cas contraire, lors de l'authentification sur GitHub, la clé privée destinée à Bitbucket pourrait être utilisée, ce qui entraînerait un échec de l'authentification.

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519

Pour tester la connectivité et vérifier la clé utilisée :

Vérifier la connectivité SSH

Exemples d'utilisation de git clone

Les exemples d' git clone s fournis jusqu'à présent couvrent les fonctionnalités de base offertes par la commande.

Dans cette section, je vais vous présenter les différentes options de la commande, qui vous permettent de personnaliser le processus de clonage d'un dépôt sur votre machine locale. Que vous travailliez avec des branches spécifiques ou que vous optimisiez la vitesse, la compréhension de ces variations vous aidera à utiliser plus efficacement git clone.

Clone du référentiel de base

Comme nous l'avons vu, l'utilisation la plus simple de l' git clone consiste à cloner un dépôt distant sur votre machine locale.

# HTTPS protocol
git clone https://github.com/aws/aws-cli.git

# SSH protocol
git clone git@github.com:aws/aws-cli.git

Ces commandes créent un dossier nommé « aws-cli » et initialisent une copie locale du référentiel à l'intérieur, avec l'historique des versions et la configuration du suivi à distance.

Cloner dans un dossier spécifique

Par défaut, l'git clone crée un répertoire nommé d'après le dépôt. Pour spécifier un autre nom de répertoire cible, veuillez le fournir en tant que deuxième argument. 

Cela clone le contenu de aws-cli.git dans le dossier local nommé my-project-folder:

git clone https://github.com/aws/aws-cli.git my-project-folder

Cloner dans un dossier spécifique

Cloner une branche ou une balise spécifique

Utilisez l'indicateur « --branch » (ou « -b ») pour vérifier la branche spécifiée après avoir cloné toutes les branches à partir du serveur distant. La branche spécifiée devient la branche « HEAD » extraite, les autres branches restant disponibles localement pour extraction.

En utilisant notre exemple de référentiel « aws-cli », la branche par défaut est develop.. Essayons de cloner et de vérifier la branche master à la place.

# Clone a branch
git clone --branch master https://github.com/aws/aws-cli.git

Cloner une branche spécifique

Nous pouvons également cloner une balise spécifique : 

# Clone a tag (read-only snapshot)
git clone --branch 2.27.43 https://github.com/aws/aws-cli.git

Cloner une balise spécifique

Ce drapeau est utile lorsque vous travaillez sur une version spécifique ou une branche liée à l'environnement (par exemple, staging, hotfix ou release).

Clone peu profond (profondeur limitée)

Si vous avez uniquement besoin de la dernière version du projet sans l'historique complet des commits, veuillez utiliser le drapeau --depth pour effectuer un clonage superficiel. Le drapeau --depth spécifie le nombre de commits que vous souhaitez cloner.

# Download only the latest commit history
git clone --depth 1 https://github.com/aws/aws-cli.git

Clone superficiel

Cela accélère le processus de clonage et réduit l'utilisation du disque, ce qui est idéal pour les pipelines CI/CD ou lorsque l'historique des commits n'est pas nécessaire. Ceci est particulièrement utile pour le référentiel « aws-cli » que nous avons cloné. Étant donné que le référentiel « aws-cli » a une longue histoire de commits, la différence de temps dans l'inclusion du drapeau d' --depth est considérable.

Différence de temps avec et sans clone superficiel

En omettant l'historique des commits, à l'exception du plus récent, nous avons réduit la quantité d'informations à télécharger et, par conséquent, le temps nécessaire.

Configurations avancées de clonage

Bien que la commande « git clone » soit généralement utilisée dans sa forme de base, Git propose plusieurs options avancées qui offrent un contrôle, une efficacité et une personnalisation accrus pendant le processus de clonage.

Ces fonctionnalités sont particulièrement utiles lorsque vous travaillez avec des référentiels volumineux, que vous gérez des référentiels au niveau de l'infrastructure ou que vous optimisez des workflows de développement spécifiques. 

Dans cette section, nous explorerons les opérations spécifiques aux branches, les clones superficiels et partiels, les spécialisations de référentiels et les configurations de clonage détaillées qui offrent de nombreuses possibilités aux développeurs et aux ingénieurs DevOps.

Opérations de clonage spécifiques à une branche

Par défaut, git clone récupère toutes les branches et vérifie celle par défaut. Cependant, lorsque vous travaillez avec de grands référentiels ou que vous contribuez à une fonctionnalité spécifique, il est souvent plus efficace de ne cloner qu'une seule branche. Ceci peut être réalisé en utilisant l'indicateur d' --single-branch.

git clone --branch <branch-name> --single-branch <repo-url>
git clone --branch feature/cliq --single-branch https://github.com/aws/aws-cli.git

Cloner une branche spécifique

Les avantages incluent une réduction de la taille et du temps de téléchargement, une configuration plus rapide pour le développement de fonctionnalités spécifiques et l'élimination de l'historique des branches inutiles.

Cette approche est idéale lorsque vous souhaitez travailler sur une branche de publication ou éviter de télécharger toutes les branches des référentiels CI/CD actifs. Si le nom de la branche n'est pas spécifié dans la commande, Git ne clonera que la branche par défaut.

Pour en savoir plus sur le clonage d'une branche spécifique, veuillez consulter le tutoriel Cloner une branche Git.

Types de référentiels spécialisés

Lorsque nous clonons un référentiel, deux composants sont clonés : le référentiel (dossier.git ) et le répertoire de travail. Le répertoire de travail est également appelé copie de travail, arborescence de travail ou espace de travail.

Différence entre le répertoire de travail et le référentiel

Le contenu du dossier « .git » est le suivant :

Contenu du dossier .git

Cela nous amène au sujet des référentiels nus.

Référentiels nus

Un référentiel vide ne contient que le dossier « .git » et aucun répertoire de travail.

git clone --bare <repo-url>
git clone --bare https://github.com/aws/aws-cli.git

Cloner un dépôt vide

D'après ce qui précède, nous pouvons constater que le contenu cloné à l'aide du drapeau « --bare » correspond simplement au contenu du dossier « .git » du référentiel non minimaliste. Comme il s'agit d'un dépôt vide, il n'y a pas de répertoire de travail, ce qui signifie que nous ne pouvons pas exécuter les commandes git, comme le montre l'image suivante :

L'opération doit être exécutée dans un répertoire de travail

Les référentiels nus sont généralement utilisés comme référentiel central dans un environnement partagé à des fins de collaboration ou de mise en miroir, plutôt que pour le développement actif. Pour illustrer le clonage à partir d'un référentiel nu, j'utiliserai le référentiel nu « aws-cli » que j'ai sur mon ordinateur local.

Cloner à partir de mon dépôt local nu

Nous pouvons constater que ce référentiel « aws-cli-non-bare » contient le répertoire de travail. Veuillez exécuter « git remote -v » pour vérifier que le référentiel nu est bien référencé.

Référentiels miroirs

La commande « git clone --mirror » configure un miroir du référentiel source. Le drapeau --mirror implique --bare, ce qui signifie que le référentiel miroir ne contient pas non plus de répertoire de travail.

git clone --mirror <repo-url>
git clone --mirror https://github.com/aws/aws-cli.git

Cloner un référentiel (central) pour créer un référentiel miroir

Cependant, contrairement à --bare, --mirror mappe non seulement les branches locales de la source vers les branches locales de la cible, mais mappe également toutes les références (y compris les branches suivies à distance, les notes, etc.) et configure une spécification de référence de sorte qu'une commande git remote update dans le référentiel cible écrase toutes ces références. Cela nous fournit une copie plus complète, incluant toutes les références (branches, balises, etc.).

Veuillez vous référer à la documentation GitHub pour connaître toutes les étapes à suivre pour mettre en miroir un référentiel.

Mise en miroir d'un référentiel à un autre emplacement. Source : GitHub

Filtres de clones partiels et réduction de la taille des clones

Les clones partiels permettent aux utilisateurs de récupérer uniquement un sous-ensemble d'objets du référentiel à l'aide du drapeau d'--filter, ce qui les rend particulièrement adaptés aux développeurs qui n'ont besoin que d'une partie d'une base de code, notamment dans les environnements soumis à des contraintes de bande passante ou d'espace disque. Voici quelques exemples courants de l'indicateur d' --filter:

• --filter=blob:none: ignore le contenu du fichier (blobs)
• --filter=blob:limit=: exclut les fichiers d'une certaine taille et plus
• --filter=tree:: omet tous les blobs et arborescences dont la profondeur par rapport à l'arborescence racine est supérieure ou égale à la profondeur définie.

blob : aucun

Le drapeau « --filter=blob:none » est utilisé pour optimiser les opérations de clonage en évitant le téléchargement immédiat du contenu des fichiers (blobs).

# Binary Large Objects (BLOB)
git clone --filter=blob:none <repo-url>
git clone --filter=blob:none https://github.com/aws/aws-cli.git

Cloner avec filtre=blob:none

Ceci est particulièrement utile dans les référentiels volumineux ou lorsqu'une partie seulement du projet est nécessaire. Par exemple, dans les monorepos, toutes les équipes ou tous les développeurs n'ont pas besoin de l'intégralité du code source. 

Un ingénieur front-end travaillant uniquement dans l'frontend/, n'a pas besoin de services back-end ni de bibliothèques partagées. L'utilisation de l'indicateur d'--filter accélère le clonage et réduit l'espace de stockage en différant le téléchargement des blobs jusqu'à ce qu'ils soient nécessaires (par exemple, lorsque le fichier est ouvert). L'image suivante illustre ce que Git effectue en arrière-plan lorsque j'ouvre un fichier, en téléchargeant le blob du fichier à la demande.

Git télécharge le blob de fichier sur demande.

Un autre exemple pourrait être celui des pipelines CI/CD. Les pipelines n'ont souvent pas besoin de l'historique complet du dépôt ni de tous les fichiers. Lorsqu'il est associé à sparse-checkout, l'option d' --filter=blob:none permet au pipeline de ne cloner que les répertoires pertinents (par exemple, les scripts de déploiement).

blob:limit=<size>

Le drapeau --filter=blob:limit= est utile pour les développeurs qui souhaitent éviter de télécharger des fichiers volumineux (blobs) lors du clonage, tout en récupérant immédiatement les fichiers plus petits. Cela fait partie de la fonctionnalité de clonage partiel de Git et s'avère particulièrement utile lorsque vous travaillez avec des dépôts contenant des contenus de tailles variées.

Par exemple, dans certains projets, en particulier ceux qui utilisent Git LFS ou qui contiennent des ressources multimédias (vidéos, ensembles de données volumineux, ressources de jeux, etc.), les développeurs peuvent souhaiter ignorer les fichiers volumineux lors du clonage, ce qui accélère le clonage initial tout en reportant le téléchargement des fichiers volumineux jusqu'à ce qu'ils soient explicitement nécessaires.

# Binary Large Objects (BLOB)
git clone --filter=blob:limit=<size> <repo-url>
#  The suffixes k, m, and g can be used to name units in KiB, MiB, or GiB
git clone --filter=blob:limit=<n>[kmg] <repo-url>
git clone --filter=blob:limit=1m https://github.com/aws/aws-cli.git

Cloner avec filtre=blob:limit

arbre :&lt;profondeur&gt;

Le drapeau --filter=tree: est utilisé pour limiter la profondeur à laquelle Git récupère les objets arborescents dans la structure du répertoire lors d'un clonage, ce qui permet de réduire la taille du transfert de données. Cela est particulièrement utile lorsque vous travaillez avec des projets profondément imbriqués, tels que les monorepos. Par exemple, si vous souhaitez inspecter rapidement une grande structure monorepo à des fins d'audit, d'intégration ou de révision, le téléchargement d'arborescences profondes est inutile.

git clone --filter=tree:<depth> <repo-url>
git clone --filter=tree:0 https://github.com/aws/aws-cli.git

Cloner avec filtre=arborescence

Veuillez noter que le serveur Git à partir duquel vous effectuez le clonage (dans ce cas, GitHub) peut ne prendre en charge que certaines valeurs pour la profondeur de filtrage de l'arborescence.

Le filtre arborescent autorise une profondeur maximale de 0.

Configuration spécifique au clone

Git propose plusieurs options pour personnaliser le comportement lors du clonage :

• --origin : définit un nom distant personnalisé à la place de l'origine.
• --template : utilise un répertoire de fichiers modèles pour la configuration initiale de l' .git
• --single-branch: évite de récupérer d'autres branches
• --recurse-submodules: initialise et clone automatiquement les sous-modules

Ces options sont utiles lors de la configuration d'environnements standardisés, lorsque vous travaillez avec des référentiels modulaires ou lors de l'intégration avec des outils de déploiement.

origine

Le drapeau --origin permet aux développeurs de personnaliser le nom de la source à partir de laquelle le référentiel est cloné. Par défaut, Git nomme le serveur distant origin, mais ce drapeau vous permet de le remplacer par un autre nom lors de l'opération de clonage.

git clone --origin <remote name> <repo-url>
# Name the remote as “upstream”
git clone --origin upstream https://github.com/aws/aws-cli.git

Veuillez renommer la télécommande « origin » en « upstream ».

Les développeurs peuvent être amenés à modifier le nom du distant pour plus de clarté, car ils peuvent être amenés à ajouter un autre distant ultérieurement (par exemple, en amont ou en dérivé). Modifier le nom de la première télécommande permet d'éviter toute confusion et tout conflit.

modèle

Le drapeau --template permet aux développeurs de spécifier un répertoire de modèles personnalisés que Git utilisera lors de la création du répertoire .git dans le nouveau dépôt cloné. Les répertoires de modèles vous permettent de prédéfinir des crochets, des fichiers de configuration ou des structures de répertoires qui sont automatiquement appliqués au référentiel lors de l'initialisation.

# Specify the directory from which templates will be used
git clone --template=<template-directory> <repo>
git clone --template=./git-template https://github.com/aws/aws-cli.git

Utilisation du drapeau --template

Je traiterai plus en détail le drapeau de modèle dans la section « Application du répertoire de modèles ».

branche unique

Le drapeau --single-branch permet de cloner uniquement l'historique de la branche spécifiée, au lieu de toutes les branches du dépôt distant. Cela peut réduire considérablement la quantité de données clonées, en particulier dans les référentiels comportant de nombreuses branches à longue durée de vie ou un historique de commits important.

Lorsque vous êtes affecté à une fonctionnalité ou à une branche de publication spécifique (par exemple, feature/login-ui, release/v2.0), il n'est pas nécessaire de cloner l'historique d'autres branches non liées.

git clone --branch feature/login-ui --single-branch <repo-url>

# If you do not specify a branch, Git will clone only the remote's default branch, usually main or master
git clone --single-branch <repo-url>
git clone --single-branch https://github.com/aws/aws-cli.git

Un cursus git clone typique suit toutes les branches distantes, comme le montre la sortie git branch -r ci-dessous.

Toutes les branches distantes sont suivies.

Alors que l'ajout de l'--single-branch e uniquement l'historique de la branche spécifiée.

Seule la branche par défaut est suivie.

récursivité des sous-modules

Les sous-modules Git sont des références à un autre référentiel, fixées à un commit spécifique. Cela vous permet de conserver l'autre dépôt Git en tant que sous-répertoire de votre dépôt Git, souvent utilisé pour inclure du code tiers, des bibliothèques partagées ou des composants spécifiques à un fournisseur. 

J'ai crééun référentiel GitHub public pour illustrer ce concept.

Démontrer les sous-modules

Lorsque nous clonons un projet contenant un sous-module, nous obtenons par défaut les répertoires contenant les sous-modules, mais pas les fichiers qu'ils contiennent.

Dossier de sous-module vide

Au lieu d'exécuter git submodule init pour initialiser votre fichier de configuration local, puis git submodule update pour récupérer toutes les données de ce projet, nous pouvons utiliser le drapeau --recurse-submodules avec la commande git clone pour initialiser et cloner automatiquement tous les sous-modules définis dans le fichier .gitmodules d'un référentiel.

git clone --recurse-submodules <repo-url>

Cloner les fichiers dans le répertoire du sous-module

Application répertoire des modèles

Git permet l'utilisation de répertoires de modèles pour définir des hooks, des configurations et d'autres fichiers par défaut lors du clonage ou de l'initialisation d'un dépôt :

La structure du répertoire des modèles peut être similaire à celle ci-dessous, avec hooks/pre-commit contenant un script shell pour bloquer les commits sans ID JIRA, et hooks/commit-msg contenant le modèle pour les messages de commit.

/home/devops/git-template/
├── config
├── description
├── hooks/
│   ├── pre-commit
│   └── commit-msg
├── info/
│   └── exclude

Une fois que vous avez défini les fichiers nécessaires dans le répertoire des modèles, vous pouvez l'utiliser pour vos opérations de clonage git.

git clone --template=</path/to/template> <repo-url>
git clone --template=/home/devops/git-template https://github.com/aws/aws-cli.git

Ceci est idéal pour :

• Application des politiques du référentiel via des hooks (par exemple, pré-commit)
• Pré-définition des fichiers de configuration pour CI/CD ou l'outillage
• Lancement de projets avec une structure commune

Les répertoires de modèles rationalisent les flux de travail des équipes et garantissent la cohérence entre les référentiels clonés.

Clonage sur différents systèmes d'exploitation

Bien que la commande « git clone » fonctionne de manière identique sur toutes les plateformes, l'expérience peut varier légèrement en fonction du système d'exploitation.

Les considérations spécifiques à l'environnement, telles que les outils de terminal, les formats de chemin d'accès aux fichiers et la gestion des autorisations, peuvent avoir une incidence sur la manière dont les développeurs interagissent avec Git. Dans cette section, je vais vous expliquer le processus de clonage sous Windows, Linux/Ubuntu et macOS afin de vous aider à comprendre toutes les subtilités.

Windows

Sous Windows, les développeurs utilisent généralement Git Bash, PowerShell ou l'invite de commande pour exécuter les commandes Git. Nous pouvons installer Git à partir de la page de téléchargement, qui comprend Git Bash, un shell de type Unix adapté à l'utilisation de Git sous Windows.

git clone dans Git Bash

git clone dans PowerShell

Quelques points à prendre en considération :

• Les chemins d'accès aux fichiers dans Git Bash utilisent le format Unix (/c/Users/username/), tandis que PowerShell et l'invite de commande utilisent le format Windows (C:\Users\username\).
• Si vous utilisez PowerShell, veuillez vous assurer que Git est ajouté au PATH de votre système.

Linux/Ubuntu

Les distributions Linux telles qu'Ubuntu offrent une expérience Git transparente via leur terminal natif. Pour l'exemple suivant, j'ai lancé une instance Ubuntu EC2 dans AWS et je m'y suis connecté via SSH.

Connectez-vous via SSH à l'instance Ubuntu EC2.

Git est installé par défaut. Toutefois, si ce n'est pas le cas, veuillez exécuter la commande « sudo apt install git ».

Installer Git sur Ubuntu

Veuillez vous rendre dans le répertoire souhaité et exécutez la commande d' git clone.

git clone sous Ubuntu

Quelques points à prendre en considération :

• Veuillez vous assurer que les clés SSH sont correctement configurées pour les référentiels privés (~/.ssh/id_rsa).
• Les autorisations d'accès aux fichiers et la propriété des répertoires peuvent affecter les opérations du référentiel, en particulier lors du clonage vers des chemins d'accès au niveau du système.

Mac

macOS fournit un environnement basé sur Unix qui ressemble étroitement à Linux, rendant les opérations Git intuitives. Git est souvent préinstallé. Si ce n'est pas le cas, l'installation des outils de ligne de commande Xcode (xcode-select --install) installera également Git.

Veuillez ouvrir le terminal et exécuter la commande « git clone ».

git clone sur Mac

Quelques points à prendre en considération :

• Comme pour Linux, la gestion des clés SSH est importante pour les référentiels privés.
• Les utilisateurs de macOS utilisent souvent des clients GUI tels que GitHub Desktop ou Sourcetree ; veuillez vous assurer que la configuration Git sous-jacente est correcte.

Scénarios de mise en œuvre pratique

Bien que la commande « git clone » soit souvent utilisée pour obtenir simplement une copie d'un référentiel, son utilité va bien au-delà dans les flux de travail d'ingénierie réels. 

Dans cette section, j'examine comment les stratégies de clonage peuvent être appliquées dans des scénarios pratiques, chacun nécessitant une approche sur mesure pour optimiser l'efficacité et la cohérence.

Flux de travail pour le développement d'entreprise

Dans les grandes organisations, il est essentiel de disposer d'un processus efficace de clonage des référentiels afin de rationaliser l'intégration des développeurs et de standardiser la configuration des projets. Les stratégies suivantes peuvent être adoptées :

• Tout d'abord, les clones peu profonds (--depth=1). Souvent utilisé pour réduire le temps de configuration pour les nouveaux développeurs qui n'ont pas besoin de l'historique complet des commits.
• Deuxièmement, les référentiels de modèles. À ne pas confondre avec les répertoires de modèles. Les référentiels de modèles contiennent des structures de dossiers prédéfinies, des hooks et des sous-modules à cloner pour un démarrage rapide des projets. Dans GitHub, vous pouvez activer un référentiel en tant que référentiel modèle en accédant aux paramètres.

Paramètres du référentiel de modèles

Une fois cette option activée, vous trouverez le bouton « Utiliser ce modèle » sur la page d'accueil de votre référentiel.

Veuillez utiliser le référentiel comme modèle.

• Enfin, le fait de disposer de miroirs internes des référentiels externes réduit la dépendance vis-à-vis des réseaux publics et accélère le clonage dans les environnements sécurisés.

Procédure de migration du référentiel

Les organisations peuvent migrer des référentiels entre différentes plateformes (par exemple, GitHub vers GitLab) pour diverses raisons, notamment pour des raisons de sécurité, de conformité ou financières. La migration nécessitera un clone miroir afin de garantir une copie complète, incluant toutes les branches, balises et l'historique des commits.

Un processus type peut se dérouler comme suit :

# --mirror flag clones all refs and configuration.
git clone --mirror https://source-url.com/your-repo.git
cd your-repo.git
git push --mirror https://target-url.com/your-new-repo.git

Cette méthode préserve mieux les métadonnées Git qu'un clonage standard suivi d'un push. Après la migration, veuillez mettre à jour les URL distantes et vérifier les autorisations d'accès.

Optimisation du pipeline CI/CD

Dans les environnements automatisés, l'optimisation des opérations de clonage permet de gagner du temps et de réduire l'utilisation des ressources, en particulier dans les déploiements à haute fréquence. Nous pouvons respecter les meilleures pratiques suivantes pour garantir un flux efficace dans le pipeline :

• Tout d'abord, veuillez utiliser des clones peu profonds (--depth=1) afin d'accélérer le démarrage des tâches.

git clone --depth 1 <repository-url>

• Deuxièmement, veuillez ne cloner que la branche requise afin d'éviter les références inutiles.

git clone --branch <branch-name> --single-branch <repo-url>

• Enfin, si plusieurs étapes de votre pipeline CI/CD nécessitent l'accès au contenu du même référentiel, envisagez de mettre en place un mécanisme de mise en cache afin d'éviter les opérations d'git clone répétées. Au lieu de cloner le référentiel à chaque étape, mettez en cache le répertoire de travail après la vérification initiale et transmettez-le comme artefact ou volume partagé aux étapes suivantes. 

Cette approche réduit considérablement les opérations redondantes, accélère l'exécution du pipeline et préserve les ressources informatiques et réseau.

Dépannage et diagnostic

Bien que la commande « git clone » soit couramment utilisée et simple, les développeurs peuvent parfois rencontrer des problèmes lors du processus de clonage, en particulier dans des environnements soumis à des contrôles d'authentification stricts, à des configurations de référentiel personnalisées ou à un accès réseau limité.

Dans cette section, je vais vous présenter les problèmes courants liés au clonage et vous expliquer comment les résoudre efficacement.

Résolution des échecs d'authentification

Les échecs d'authentification se produisent généralement lors de l'accès à des référentiels privés ou lors de l'utilisation d'informations d'identification expirées. Selon le protocole utilisé, HTTPS ou SSH, différents messages d'erreur et solutions s'appliquent. Dans les environnements compatibles MFA, il est recommandé de toujours privilégier SSH ou HTTPS avec PAT.

Pour le protocole HTTPS, une erreur courante est l'échec de l'authentification. Cela peut être dû à l'utilisation d'un jeton d'accès personnel expiré. Si l'authentification multifacteur est activée, il est également possible que le jeton d'accès personnel n'ait pas été utilisé comme mot de passe.

Échec de l'authentification HTTPS

Pour SSH, une erreur courante serait l'erreur « Permission refusée (clé publique) ». Cela peut être dû au fait que la clé publique n'a pas été ajoutée au compte du fournisseur Git ou que la clé privée stockée sur votre appareil local ne se trouve pas dans le répertoire approprié.

Échec de l'authentification SSH

Vous pouvez vérifier la connectivité à l'aide de :

ssh -T git@github.com

Récupération partielle d'objets clones

Dans de rares cas, lorsque vous utilisez des clones partiels ( drapeaux --filter ou --depth ), vous pouvez rencontrer des objets manquants (par exemple, « error: object &lt;sha&gt; is missing ») si Git tente d'accéder à des parties du référentiel qui n'ont pas été récupérées initialement.

Je n'ai jamais rencontré cette situation auparavant. Toutefois, vous pourriez rencontrer des erreurs lors de l'accès aux commits, branches ou balises historiques. Si cela se produit dans un pipeline, les outils ou scripts de compilation risquent d'échouer. Vous pouvez récupérer explicitement les données manquantes en utilisant :

# Have Git refetch all objects from the remote, even if it thinks it already has them.
# For dealing with a broken or corrupted partial clone
git fetch --filter=blob:none --refetch

# Convert a shallow clone into a full clone. Retrieves the rest of the commit history that was omitted during the shallow clone.
git fetch --unshallow

# Obtain a deeper history of the branch
git fetch origin <branch> --depth=50

# Fetches 30 more commits from the current branch’s history. Repeat as needed.
git fetch --deepen=30

Demander à Git de récupérer tous les objets à partir du serveur distant

Messages d'erreur courants lors de la clonage Git et solutions

Outre les problèmes mentionnés ci-dessus auxquels vous pourriez être confronté lors de l' git clone, le tableau suivant répertorie d'autres erreurs courantes.

Conclusion

La commande « git clone » peut sembler simple à première vue, et pour beaucoup, son utilisation de base s'est avérée suffisante. Cependant, comme cet article l'a démontré, il s'agit d'un outil fondamental aux applications très variées. 

Nous avons abordé le fonctionnement de l' git clone, exploré les types d'URL et les protocoles, passé en revue les configurations avancées et les comportements spécifiques aux systèmes d'exploitation, et examiné des scénarios concrets tels que l'intégration continue/le développement continu (CI/CD), les workflows d'entreprise et les techniques de dépannage courantes.

L'adaptation de l'git clone à votre environnement, que ce soit pour des clones peu profonds dans des pipelines, des migrations de référentiels ou une collaboration à grande échelle, peut considérablement améliorer les performances et l'efficacité de votre équipe. À mesure que les environnements de développement modernes deviennent de plus en plus complexes et distribués, la maîtrise de ces configurations vous garantit non seulement d'utiliser Git, mais également de l'utiliser efficacement.

À l'avenir, les mécanismes de clonage de Git pourraient être améliorés, notamment grâce à des clones partiels plus intelligents, une meilleure prise en charge des monorepos volumineux et une gestion plus intuitive des sous-modules et des filtres. À mesure que Git évolue, rester informé de ces améliorations permettra aux développeurs de travailler plus rapidement et plus efficacement, quel que soit le système ou l'échelle.

Pour en savoir plus sur Git, je vous recommandede suivre le cours Introduction à Git. Si vous souhaitez approfondir vos compétences, le cours Git avancé est fait pour vous.