Git-clone-commando: van basisgebruik tot geavanceerde technieken

Git-URL’s en -protocollen

Zoals je in het bovenstaande voorbeeld van het klonen van de “aws-cli”-repository ziet, moeten we om een repository te klonen met git clone de locatie van de externe repository opgeven, en dat gebeurt via een Git-URL. 

Git ondersteunt meerdere protocollen om toegang te krijgen tot externe repositories, elk met een eigen structuur, beveiligingsmodel en beste use-cases. Door de verschillende typen Git-URL’s te begrijpen en te weten wanneer je welk type gebruikt, kun je veiliger en efficiënter werken, vooral bij samenwerking tussen teams of tijdens geautomatiseerde deployments.

Typen Git-URL’s

Bij het klonen van een repository vertelt de URL die je opgeeft aan Git hoe het met de externe server moet verbinden. De meest voorkomende typen Git-URL’s zijn:

HTTPS

Hyper Text Transfer Protocol Secure (HTTPS). Wordt het meest gebruikt om webpagina’s via een browser te benaderen. Dit URL-type is eenvoudig te gebruiken en vereist geen setup bij het klonen van een openbare repository. Enkele voorbeelden:

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.gitMogelijk gemaakt door

Uitleg van de structuur:

• https:// – Protocol voor communicatie (veilig en firewallvriendelijk).
• github.com – Domein van de Git-hostingdienst.
• username/repo.git – Pad naar de repository:
• username is de eigenaar (gebruiker of organisatie)
• repo.git is de naam van de Git-repository

SSH

Secure Shell (SSH). Een geauthenticeerd netwerkprotocol dat vereist dat je eerst je credentials bij de hostingserver configureert. Vereist het genereren van een SSH-sleutelpaar en het toevoegen van de publieke sleutel aan je Git-provider (bijv. GitHub, GitLab)

git clone [email protected]:<username>/<repo>.git
git clone [email protected]:aws/aws-cli.git
git clone [email protected]:gitlab-org/gitlab.gitMogelijk gemaakt door

Uitleg van de structuur:

• git@ – Specificeert het SSH-gebruikersaccount (meestal gewoon git).
• github.com: – Domein van de Git-server, gevolgd door een dubbelepunt : (geen slash).
• username/repo.git – Pad naar de repository op de server.

Omdat ik geen SSH-sleutels heb geconfigureerd op mijn GitHub-account, verschijnt het volgende bericht wanneer ik probeer de SSH-URL te kopiëren.

Geen SSH-sleutel ingesteld

In de volgende sectie behandel ik het instellen van SSH-sleutels.

GIT

Een lichtgewicht, niet-geauthenticeerd protocol voor alleen-lezen toegang. Het is een protocol dat uniek is voor git. Tegenwoordig wordt het zelden gebruikt vanwege beveiligingszorgen en het uitfaseren door grote aanbieders zoals GitHub en GitLab. Je vindt op GitHub of GitLab zelfs niet meer de optie om met het git-protocol te klonen.

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

Uitleg van de structuur:

• git// – Git-protocol (alleen-lezen, niet-geauthenticeerd).
• github.com: – Domein van de Git-server.
• username/repo.git – Pad naar de repository op de server.

Ongeacht het gebruikte kloonprotocol kun je de URL en het protocol controleren met de volgende commando’s:

git remote -v
git remote show originMogelijk gemaakt door

Het juiste URL-protocol kiezen

Elk protocol heeft voor- en nadelen. Met de volgende tabel vergelijken we de plus- en minpunten om het juiste protocol voor jouw use-case te kiezen.

Protocol-specifieke kloonprocedures

Als je een Git-URL-protocol hebt gekozen, verschillen het eigenlijke kloonproces en de authenticatiestroom. Hoewel beide methoden uiteindelijk hetzelfde doel bereiken (een externe repository naar je lokale machine klonen), sluiten ze aan bij verschillende beveiligingsvoorkeuren, gebruikersbehoeften en setupcomplexiteit. 

In deze sectie behandel ik het klonen van een repository met zowel HTTPS als SSH, inclusief best practices, stappen voor de configuratie en tips voor probleemoplossing om een veilig en soepel kloonproces te garanderen.

HTTPS Git-kloonworkflow

Een Git-repository klonen via HTTPS is de meest eenvoudige methode, ideaal voor beginners en beperkte omgevingen (zoals bedrijfsfirewalls of beperkte netwerken).

Om een repository te klonen, navigeer je ernaartoe en kopieer je de HTTPS-URL. De onderstaande afbeelding komt van GitHub. Bij jouw Git-provider is dit vergelijkbaar.

Verkrijg de HTTPS-URL van een repository op GitHub

Voer daarna het git clone-commando uit op de bestemming (bijv. je laptop of een CI/CD-pijplijn) waar je de repository wilt klonen.

git clone https://github.com/aws/aws-cli.gitMogelijk gemaakt door

Basiscommando voor git clone

Voor het klonen van een openbare repository, zoals we met de “aws-cli”-repository hebben gedaan, is geen authenticatie vereist omdat de repository openbaar is. Zolang je git op je systeem hebt geïnstalleerd, kun je de openbare repo direct klonen zonder verdere configuratie.

Als je echter een privérepository kloont, is authenticatie vereist. Je kunt authenticeren via:

• Personal Access Token
• Passkeys

Om authenticatie via een personal access token te demonstreren, heb ik een server opgestart in AWS EC2 en Git geïnstalleerd. Bij het uitvoeren van het git clone-commando op een privérepository wordt om een gebruikersnaam en wachtwoord gevraagd. Voer je GitHub-gebruikersnaam in als gebruikersnaam en je personal access token als wachtwoord.

HTTPS-authenticatie via gebruikersnaam/wachtwoord

Door aangescherpte beveiligingsregels vereisen GitHub en andere providers nu een personal access token in plaats van een wachtwoord.

 

Instructies voor toegangstokens bij klonen met HTTPS-URL’s. Bron: GitHub

Je krijgt de volgende foutmelding als je je personal access token niet invoert:

Ondersteuning voor wachtwoordauthenticatie is verwijderd.

Om een personal access token te maken, ga naar Create a GitHub Token en volg de instructies: 

Maak een personal access token aan op GitHub

Om te voorkomen dat je je personal access token telkens moet invoeren wanneer Git authenticatie via HTTPS vereist, kun je een credential helper gebruiken om je inloggegevens veilig te cachen. Een populaire optie is de Git Credential Manager. 

Op macOS integreert Git naadloos met de macOS-sleutelhanger, die ik persoonlijk gebruik om mijn gegevens op te slaan. In mijn geval authenticeer ik met passkeys die in de sleutelhanger zijn opgeslagen, wat voor een veilige en soepele ervaring zorgt.

Bekijk de credential helper

Passkeys op macOS

Om een passkey in te stellen, ga je naar GitHub’s wachtwoord- en authenticatie-instellingen en volg je de stappen.

Maak een passkey aan op GitHub

Hoewel GitHub je toestaat een niet-verlopend personal access token te maken, hanteren de meeste organisaties beveiligingsbeleid dat vereist dat tokens een verloopdatum hebben. Dit betekent dat als een token in geautomatiseerde omgevingen, zoals CI/CD-pijplijnen, wordt gebruikt en verloopt, de pijplijn zal falen door authenticatiefouten. Het is essentieel om het token proactief te vernieuwen vóórdat het verloopt en het gebruik ervan bij te werken.

Zonder goede afspraken kunnen ontwikkelaars per ongeluk meerdere personal access tokens aanmaken en gebruiken zonder duidelijke documentatie of tracking. Dat kan snel leiden tot onduidelijkheid over welk token waar wordt gebruikt, waardoor onderhoud en audits lastiger worden. Voor betere hygiëne is het aan te raden het gebruik van tokens minimaal, gedocumenteerd en gekoppeld aan specifieke use-cases te houden.

SSH-kloonmethode

SSH biedt een veilige en blijvende authenticatiemethode, vooral geschikt voor frequente bijdragers en gevorderde gebruikers. Eenmaal ingesteld, kun je repositories naadloos benaderen zonder herhaalde inlogprompts.

Om SSH-authenticatie in te stellen, moeten we eerst een SSH-sleutelpaar genereren, dat bestaat uit een publieke en private sleutel.

# ed25519 specifies the key type
ssh-keygen -t ed25519 -C "[email protected]"Mogelijk gemaakt door

Maak een SSH-sleutelpaar aan

Omdat ik al een bestaande SSH-sleutel heb in ~/.ssh/id_ed25519, heb ik de standaardmap overschreven waarin de sleutels worden geplaatst. Maar als je voor het eerst een SSH-sleutel op je apparaat aanmaakt, accepteer dan de standaardmap.

Navigeer naar SSH and GPC keys in GitHub om je SSH-sleutel in te stellen.

Stel een SSH-sleutel in op GitHub

Kopieer de inhoud van de publieke sleutel in het veld “Key”. In mijn geval is dat de inhoud van id_ed25519.pub.

Plak de inhoud van id_ed25519.pub

SSH gebruikt public/private key-encryptie. Bewaar je private sleutel veilig op je machine. Daarmee ben je klaar om via SSH een repository te klonen, openbaar of privé.

Na het succesvol instellen van SSH wordt er bij het selecteren van de SSH-URL geen waarschuwingsbericht meer weergegeven, zoals te zien was in de sectie “Typen Git-URL’s”.

Verkrijg de SSH-URL van een repository op GitHub

Omdat de SSH-private sleutel op mijn lokale apparaat staat, demonstreer ik git clone via SSH op mijn lokale machine in plaats van op de EC2-server.

git clone [email protected]:aws/aws-cli.gitMogelijk gemaakt door

Kloon openbare en privérepositories met SSH

We hebben de git clone-actie via SSH succesvol uitgevoerd!

De voordelen van SSH zijn onder meer de veiligheid en het brede gebruik binnen organisaties, omdat het wachtwoordloze authenticatie mogelijk maakt—ideaal bij frequente interacties. SSH-verbindingen zijn ook veerkrachtig bij netwerkonderbrekingen en vaak sneller dan HTTPS over lange afstanden.

Toch lopen ontwikkelaars vaak tegen problemen aan tijdens het instellen van SSH-sleutels, bijvoorbeeld doordat ze de verkeerde publieke sleutel naar de Git-provider kopiëren. Als je meerdere private sleutels voor verschillende doeleinden hebt, moet je in het ~/.ssh/config-bestand definiëren welke sleutel per host gebruikt moet worden. Anders kan bij authenticatie naar GitHub de private sleutel voor Bitbucket worden gebruikt, met een authenticatiefout tot gevolg.

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519Mogelijk gemaakt door

Om de connectiviteit te testen en te verifiëren welke sleutel wordt gebruikt:

Verifieer SSH-connectiviteit

Voorbeelden van git clone-gebruik

De voorbeelden van git clone tot nu toe behandelen de basisfunctionaliteit van het commando. 

In deze sectie neem ik je mee door de verschillende opties van het commando, waarmee je het kloonproces van een repository kunt afstemmen op je lokale machine. Of je nu met specifieke branches werkt of optimaliseert voor snelheid, inzicht in deze varianten helpt je git clone effectiever te gebruiken.

Basisrepository klonen

Het meest eenvoudige gebruik van git clone, zoals we hebben gezien, houdt in dat je een externe repository naar je lokale machine kloont.

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

# SSH protocol
git clone [email protected]:aws/aws-cli.gitMogelijk gemaakt door

Deze commando's maken een map met de naam "aws-cli" en initialiseren daarin een lokale kopie van de repository, inclusief de versiegeschiedenis en de configuratie voor tracking van de remote.

Klonen naar een specifieke map

Standaard maakt git clone een directory met de naam van de repo. Wil je een andere doelmapnaam opgeven, geef die dan mee als tweede argument. 

Dit kloont de inhoud van aws-cli.git naar de lokale map met de naam my-project-folder:

git clone https://github.com/aws/aws-cli.git my-project-folderMogelijk gemaakt door

Klonen naar een specifieke map

Een specifieke branch of tag klonen

Gebruik de vlag --branch (of -b) om na het klonen van alle branches van de remote naar de opgegeven branch te checken. De opgegeven branch wordt de uitgecheckte "HEAD" en de andere branches zijn lokaal beschikbaar om naar over te schakelen.

In het voorbeeld van onze "aws-cli"-repository is de standaardbranch develop. Laten we in plaats daarvan de master-branch klonen en uitchecken.

# Een branch klonen
git clone --branch master https://github.com/aws/aws-cli.gitMogelijk gemaakt door

Een specifieke branch klonen

We kunnen ook een specifieke tag klonen: 

# Een tag klonen (alleen-lezen snapshot)
git clone --branch 2.27.43 https://github.com/aws/aws-cli.gitMogelijk gemaakt door

Een specifieke tag klonen

Deze vlag is handig wanneer je werkt aan een specifieke versie of een omgevingsgerelateerde branch (bijv. staging, hotfix of release).

Shallow clone (beperkte diepte)

Als je alleen de nieuwste versie van het project nodig hebt zonder de volledige commitgeschiedenis, gebruik dan de vlag --depth om een shallow clone uit te voeren. Met de vlag --depth geef je aan hoeveel commits je wilt klonen.

# Download alleen de nieuwste commitgeschiedenis
git clone --depth 1 https://github.com/aws/aws-cli.gitMogelijk gemaakt door

Shallow clone

Dit versnelt het kloonproces en vermindert het schijfgebruik, ideaal voor CI/CD-pijplijnen of wanneer je niet geïnteresseerd bent in de commitgeschiedenis. Dit is vooral nuttig voor de "aws-cli"-repository die we aan het klonen zijn. Omdat de "aws-cli"-repository een lange commitgeschiedenis heeft, is het tijdsverschil bij het opnemen van de vlag --depth enorm.

Tijdsverschil met en zonder shallow clone

Door de commitgeschiedenis weg te laten, behalve de laatste, hoefde er minder informatie gedownload te worden en dus nam de benodigde tijd af.

Geavanceerde kloonconfiguraties

Hoewel het commando git clone meestal in zijn basisvorm wordt gebruikt, biedt Git verschillende geavanceerde opties die tijdens het klonen meer controle, efficiëntie en maatwerk mogelijk maken. 

Deze functies zijn vooral nuttig bij grote repositories, het beheren van infrastructuurniveau-repositories of het optimaliseren voor specifieke ontwikkelworkflows. 

In deze sectie verkennen we branch-specifieke operaties, shallow en gedeeltelijke clones, specialisaties van repositories en fijnmazige kloonconfiguraties die zowel developers als DevOps-engineers in hun kracht zetten.

Branch-specifieke kloonoperaties

Standaard haalt git clone alle branches op en checkt de standaardbranch uit. Maar bij grote repositories of wanneer je aan een specifieke feature bijdraagt, is het vaak efficiënter om slechts één branch te klonen. Dat kan met de vlag --single-branch.

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

Een specifieke branch klonen

De voordelen zijn een kleinere downloadgrootte en -tijd, snellere setup voor feature-specifieke ontwikkeling en het vermijden van onnodige branchgeschiedenis.

Deze aanpak is ideaal wanneer je aan een releasebranch wilt werken of wilt voorkomen dat je alle branches in actieve CI/CD-repositories downloadt. Als de branchnaam niet in het commando is opgegeven, kloont Git alleen de standaardbranch.

Wil je meer begrijpen over het klonen van een specifieke branch, bekijk dan de Git Clone Branch-tutorial.

Gespecialiseerde repositorytypen

Wanneer we een repository klonen, worden twee componenten gekloond: de repository (.git-map) en de werkdirectory. De werkdirectory wordt ook wel de working copy, work tree of workspace genoemd.

Verschil tussen werkdirectory en repository

De inhoud van de map .git is als volgt:

Inhoud van .git-map

Dit brengt ons bij het onderwerp van een bare repository.

Bare repositories

Een bare repository bevat alleen de map .git en geen werkdirectory.

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

Een bare repository klonen

Hierboven zien we dat de inhoud die is gekloond met de vlag --bare simpelweg de inhoud is van de map .git van de niet-bare repository. Omdat dit een bare repository is, is er geen werkdirectory, wat betekent dat we de git-commando's niet kunnen draaien, zoals te zien in de volgende afbeelding:

Operatie moet in een work tree worden uitgevoerd

Bare repositories worden doorgaans gebruikt als centrale repository in een gedeelde omgeving voor samenwerking of mirroring, en niet voor actieve ontwikkeling. Om het klonen vanaf de bare repository te demonstreren, gebruik ik de bare "aws-cli"-repository die ik lokaal heb.

Klonen vanaf mijn lokale bare-repository

We zien dat deze "aws-cli-non-bare"-repository de werkdirectory bevat. Voer git remote -v uit om te zien dat deze verwijst naar de bare repository.

Gespiegelde repositories

Het commando git clone --mirror zet een spiegel op van de bronrepository. De vlag --mirror impliceert --bare, wat betekent dat de spiegelrepository ook geen werkdirectory bevat. 

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

Kloon een (centrale) repository om een spiegelrepository te maken

Vergeleken met --bare geldt echter dat --mirror niet alleen lokale branches van de bron naar lokale branches van het doel mapt, maar alle refs (inclusief remote-tracking branches, notes, enz.) en een refspec-configuratie instelt zodat een git remote update in de doelrepository al deze refs overschrijft. Dit geeft ons een vollediger kopie, inclusief alle referenties (branches, tags, enz.).

Je kunt de GitHub-documentatie raadplegen voor de volledige stappen om een repository te spiegelen.

Een repository op een andere locatie spiegelen. Bron: GitHub

Gedeeltelijke kloonfilters en kloonomvang verkleinen

Gedeeltelijke clones stellen gebruikers in staat om slechts een subset van repository-objecten op te halen met de vlag --filter. Dit is ideaal voor developers die slechts een deel van een codebase nodig hebben, vooral in omgevingen met beperkingen op bandbreedte of schijfruimte. Enkele veelvoorkomende voorbeelden van de vlag --filter zijn:

• --filter=blob:none: slaat bestandsinhoud (blobs) over
• --filter=blob:limit=<size>: sluit bestanden uit vanaf een bepaalde grootte
• --filter=tree:<depth>: laat alle blobs en trees weg waarvan de diepte vanaf de root tree groter dan of gelijk aan de opgegeven diepte is.

blob:none

De vlag --filter=blob:none wordt gebruikt om kloonbewerkingen te optimaliseren door het direct downloaden van bestandsinhoud (blobs) te vermijden. 

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

Klonen met filter=blob:none

Dit is vooral nuttig in grote repositories of wanneer slechts een subset van het project nodig is. In monorepo's hebben bijvoorbeeld niet alle teams of developers de volledige codebase nodig. 

Een frontend-engineer die alleen in frontend/ werkt, heeft geen back-endservices of gedeelde libraries nodig. Met de vlag --filter versnel je het klonen en beperk je opslag door het downloaden van blobs uit te stellen tot het moment dat ze nodig zijn (bijv. wanneer het bestand wordt geopend). De volgende afbeelding laat zien wat Git op de achtergrond doet wanneer ik een bestand open: de file blob on demand downloaden.

Git downloadt de file blob on demand

Nog een voorbeeld is in CI/CD-pijplijnen. Pijplijnen hebben vaak niet de volledige repo-geschiedenis of elk bestand nodig. In combinatie met sparse-checkout laat --filter=blob:none de pijplijn alleen relevante mappen klonen (bijv. deployscripts).

blob:limit=<size>

De vlag --filter=blob:limit=<size> is handig voor developers die grote bestanden (blobs) tijdens het klonen willen overslaan, terwijl kleinere bestanden wel direct worden opgehaald. Dit maakt deel uit van Git's partial clone-functionaliteit en is vooral nuttig bij repositories met content van verschillende groottes.

In sommige projecten, vooral die Git LFS gebruiken of mediabestanden hebben ingecheckt (bijv. video's, grote datasets, game-assets), willen developers grote bestanden mogelijk overslaan tijdens het klonen, zodat de initiële clone sneller is en grote bestanden pas worden gedownload wanneer ze expliciet nodig zijn.

# 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.gitMogelijk gemaakt door

Klonen met filter=blob:limit

tree:<depth>

De vlag --filter=tree:<depth> wordt gebruikt om te beperken hoe diep in de mapstructuur Git tree-objecten ophaalt tijdens een clone. Dit helpt de hoeveelheid data te verkleinen, en is vooral handig bij projecten met diepe structuren, zoals monorepo's. Als je bijvoorbeeld snel de structuur van een grote monorepo wilt inspecteren voor auditing, onboarding of review, is het downloaden van diepe trees verspilling.

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

Klonen met filter=tree

Let erop dat de Git-server waarvan je kloont (in dit geval GitHub) mogelijk slechts bepaalde waarden voor de diepte van tree-filtering ondersteunt.

Tree-filter staat maximale diepte 0 toe

Kloonspecifieke configuratie

Git biedt verschillende opties om het gedrag tijdens het klonen aan te passen:

• --origin <name>: stelt een aangepaste remote-naam in in plaats van origin
• --template <dir>: gebruikt een map met templatebestanden voor de initiële .git-setup
• --single-branch: voorkomt het ophalen van andere branches
• --recurse-submodules: initialiseert en kloont submodules automatisch

Deze opties zijn handig bij het opzetten van gestandaardiseerde omgevingen, werken met modulaire repositories of integratie met deploymenttools.

origin

Met de vlag --origin <name> kunnen developers de naam aanpassen van de remote waarvan de repository wordt gekloond. Standaard noemt Git de remote origin, maar met deze vlag kun je die tijdens het klonen wijzigen.

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

Hernoem de remote van origin naar upstream

Developers kunnen de remote-naam willen wijzigen voor duidelijkheid, omdat ze later mogelijk nog een remote moeten toevoegen (bijv. upstream vs. geforkte origin). Het wijzigen van de naam van de eerste remote helpt verwarring en conflicten te voorkomen.

template

De vlag --template stelt developers in staat een aangepaste templatemap op te geven die Git gebruikt bij het aanmaken van de .git-directory in de nieuw gekloonde repository. Templatemappen laten je hooks, configuratiebestanden of mapstructuren vooraf definiëren die automatisch op de repository worden toegepast tijdens initialisatie.

# Geef de map op waaruit templates worden gebruikt
git clone --template=<template-directory> <repo>
git clone --template=./git-template https://github.com/aws/aws-cli.gitMogelijk gemaakt door

Gebruik van de vlag --template

Ik ga verder in op de template-vlag in de sectie "Toepassing van de templatemap".

single-branch

De vlag --single-branch wordt gebruikt om alleen de geschiedenis van de opgegeven branch te klonen in plaats van alle branches in de remote repository. Dit kan de hoeveelheid gekloonde data aanzienlijk verminderen, vooral bij repositories met veel langlopende branches of een grote commitgeschiedenis.

Als je wordt toegewezen aan een specifieke feature- of releasebranch (bijv. feature/login-ui, release/v2.0), is het niet nodig om de geschiedenis van andere, niet-gerelateerde branches te klonen.

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

# Als je geen branch opgeeft, kloont Git alleen de standaardbranch van de remote, meestal main of master
git clone --single-branch <repo-url>
git clone --single-branch https://github.com/aws/aws-cli.gitMogelijk gemaakt door

Een typische git clone volgt alle remote branches, zoals te zien is in de uitvoer van git branch -r hieronder.

Alle remote branches worden gevolgd

Terwijl het toevoegen van --single-branch ervoor zorgt dat alleen de geschiedenis van de opgegeven branch wordt gekloond.

Alleen de standaardbranch wordt gevolgd

recurse-submodules

Git-submodules zijn een verwijzing naar een andere repository, vastgezet op een specifieke commit. Zo kun je een andere Git-repository als subdirectory in je eigen repository opnemen, vaak gebruikt voor derde-partijcode, gedeelde libraries of leveranciersspecifieke componenten. 

Ik heb een publieke GitHub-repository gemaakt om dit concept te demonstreren.

Submodules demonstreren

Wanneer we een project klonen met een submodule erin, krijgen we standaard de mappen die de submodules bevatten, maar niet de bestanden erin.

Lege submodulemap

In plaats van git submodule init uit te voeren om je lokale configuratiebestand te initialiseren, en git submodule update om alle data van dat project op te halen, kunnen we de vlag --recurse-submodules gebruiken met het commando git clone om automatisch alle submodules te initialiseren en te klonen die zijn gedefinieerd in het .gitmodules-bestand van een repository.

git clone --recurse-submodules <repo-url>Mogelijk gemaakt door

Bestanden binnen de submodulemap klonen

Toepassing van de templatemap

Git ondersteunt het gebruik van templatemappen om standaard hooks, configs en andere bestanden te definiëren tijdens het klonen of initialiseren van repositories:

De structuur van de templatemap kan lijken op die hieronder, waarbij hooks/pre-commit een shellscript-hook bevat om commits zonder JIRA-ID te blokkeren, en hooks/commit-msg de template voor commitberichten bevat.

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

Nadat je de benodigde bestanden in de templatemap hebt gedefinieerd, kun je deze gebruiken bij je git clone-operaties.

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

Dit is ideaal voor:

• Het afdwingen van repositorypolicy's via hooks (bijv. pre-commit)
• Het vooraf definiëren van configbestanden voor CI/CD of tooling
• Projecten opzetten met een gemeenschappelijke structuur

Templatemappen stroomlijnen teamworkflows en zorgen voor consistentie tussen gekloonde repositories.

Klonen op verschillende besturingssystemen

Hoewel het git clone-commando op alle platformen in de kern hetzelfde werkt, kan de ervaring per besturingssysteem net iets verschillen. 

Omgevingsspecifieke aandachtspunten—zoals terminaltools, bestands padformaten en permissiebeheer—kunnen invloed hebben op hoe developers met Git werken. In deze sectie bespreek ik het kloonproces op Windows, Linux/Ubuntu en macOS, zodat je eventuele nuances kunt ondervangen.

Windows

Op Windows gebruiken developers doorgaans Git Bash, PowerShell of de Opdrachtprompt om Git-commando's uit te voeren. We kunnen Git installeren via de downloadpagina, die Git Bash meelevert: een Unix-achtige shell die is afgestemd op Git-gebruik op Windows.

git clone in Git Bash

git clone in PowerShell

Een paar aandachtspunten:

• Bestandspaden in Git Bash gebruiken het Unix-formaat (/c/Users/username/), terwijl PowerShell en Opdrachtprompt het Windows-formaat gebruiken (C:\Users\username\).
• Zorg er in PowerShell voor dat Git is toegevoegd aan de PATH-variabele van je systeem.

Linux/Ubuntu

Linux-distributies zoals Ubuntu bieden een naadloze Git-ervaring via de eigen terminal. Voor het volgende voorbeeld heb ik een Ubuntu EC2-instance in AWS opgestart en er via SSH verbinding mee gemaakt.

SSH naar de Ubuntu EC2-instance

Git was standaard geïnstalleerd. Als het bij jou niet zo is, voer dan simpelweg het commando sudo apt install git uit.

Git installeren op Ubuntu

Navigeer naar je gewenste map en voer het commando git clone uit.

git clone in Ubuntu

Een paar aandachtspunten:

• Zorg dat SSH-sleutels goed zijn geconfigureerd voor privérepositories (~/.ssh/id_rsa).
• Bestandsrechten en map-eigenaarschap kunnen invloed hebben op repository-bewerkingen, vooral bij klonen naar systeempaden.

Mac

macOS biedt een Unix-omgeving die sterk lijkt op Linux, waardoor Git-werkzaamheden intuïtief zijn. Git is vaak vooraf geïnstalleerd. Zo niet, dan installeert het installeren van Xcode Command Line Tools (xcode-select --install) ook Git.

Open Terminal en voer het commando git clone uit.

git clone op Mac

Een paar aandachtspunten:

• Net als bij Linux is het beheren van SSH-sleutels belangrijk voor private repositories.
• macOS-gebruikers gebruiken vaak GUI-clients zoals GitHub Desktop of Sourcetree; zorg ervoor dat de onderliggende Git-configuratie correct is ingesteld.

Praktische implementatiescenario’s

Hoewel git clone vaak wordt gebruikt om simpelweg een kopie van een repository te verkrijgen, reikt de meerwaarde in echte engineeringworkflows veel verder.

In dit onderdeel bekijk ik hoe kloonstrategieën kunnen worden toegepast in praktische scenario’s, die elk een gerichte aanpak vereisen om efficiëntie en consistentie te maximaliseren.

Enterprise-ontwikkelworkflow

In grote organisaties is efficiënt klonen van repositories cruciaal om het onboarden van developers te stroomlijnen en projectsetups te standaardiseren. De volgende strategieën kunnen worden toegepast:

• Ten eerste, shallow clones (--depth=1). Vaak gebruikt om de installatietijd voor nieuwe developers te verkorten wanneer de volledige commitgeschiedenis niet nodig is.
• Ten tweede, template-repositories. Niet te verwarren met templatemappen. Template-repositories bevatten vooraf gedefinieerde mapstructuren, hooks en submodules die worden gekloond voor een snelle projectstart. In GitHub kun je in de instellingen een repository als template-repository inschakelen.

Instelling voor template-repository

Na het inschakelen vind je de knop “Use this template” op de startpagina van je repository.

Gebruik de repository als template

• Tot slot: interne mirrors van externe repositories verkleinen de afhankelijkheid van publieke netwerken en versnellen het klonen in beveiligde omgevingen.

Procedure voor repositorymigratie

Organisaties kunnen repositories migreren tussen platforms (bijv. van GitHub naar GitLab) om verschillende redenen, waaronder beveiliging, compliance of financiële overwegingen. De migratie vereist een mirror-clone om een volledige kopie te garanderen, inclusief alle branches, tags en commitgeschiedenis.

Een typisch proces kan er als volgt uitzien:

# --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.gitMogelijk gemaakt door

Deze methode behoudt Git-metadata beter dan een standaard clone gevolgd door een push. Werk na de migratie de remote-URL’s bij en controleer de toegangsrechten.

Optimalisatie van CI/CD-pipelines

In geautomatiseerde omgevingen bespaart het optimaliseren van clone-operaties tijd en verlaagt het het verbruik van resources, vooral bij deploys met hoge frequentie. We kunnen de volgende best practices volgen om een efficiënte pipelineflow te waarborgen:

• Ten eerste, gebruik shallow clones (--depth=1) om de starttijd van jobs te versnellen.

git clone --depth 1 <repository-url>Mogelijk gemaakt door

• Ten tweede, clone alleen de vereiste branch om onnodige refs te vermijden.

git clone --branch <branch-name> --single-branch <repo-url>Mogelijk gemaakt door

• Tot slot, als meerdere stages in je CI/CD-pipeline toegang nodig hebben tot dezelfde repository-inhoud, overweeg dan een cachingmechanisme om herhaalde git clone-operaties te vermijden. In plaats van in elke stage de repository te klonen, cache je de werkdirectory na de eerste checkout en geef je die door als een artifact of gedeelde volume aan volgende stages.

Deze aanpak vermindert herhalingswerk aanzienlijk, versnelt de pipeline-uitvoering en spaart compute- en netwerkresources.

Probleemoplossing en diagnostiek

Hoewel git clone een veelgebruikt en eenvoudig commando is, kunnen developers af en toe problemen tegenkomen tijdens het kloonproces, vooral in omgevingen met strikte authenticatiecontroles, aangepaste repositoryconfiguraties of beperkte netwerktoegang.

In dit onderdeel neem ik de meest voorkomende kloonproblemen door en laat ik zien hoe je die efficiënt oplost.

Oplossingen bij authenticatiefouten

Authenticatiefouten treden meestal op bij toegang tot private repositories of bij verlopen inloggegevens. Afhankelijk van het protocol, HTTPS of SSH, horen daar verschillende foutmeldingen en oplossingen bij. In omgevingen met MFA geniet SSH of HTTPS met PAT’s altijd de voorkeur.

Voor HTTPS is een veelvoorkomende fout de authentication failure. Dit kan het gevolg zijn van een verlopen personal access token. Als MFA is ingeschakeld, kan een andere mogelijke reden zijn dat het personal access token niet als wachtwoord is gebruikt.

HTTPS-authenticatiefout

Voor SSH is een veelvoorkomende fout de melding “Permission denied (publickey)”. Dit kan komen doordat de public key niet is toegevoegd aan het account bij de Git-provider, of doordat de private key op je lokale apparaat niet in de juiste map staat.

SSH-authenticatiefout

Je kunt de connectiviteit valideren met:

ssh -T [email protected]Mogelijk gemaakt door

Objecten ophalen bij partial clone

Zelden, wanneer je partial clones gebruikt (--filter of --depth flags), kun je missende objecten tegenkomen (bijv. “error: object <sha> is missing”) als Git toegang probeert te krijgen tot delen van de repository die in eerste instantie niet zijn opgehaald.

Ik heb deze situatie zelf nog niet meegemaakt. Toch kun je fouten krijgen bij toegang tot historische commits, branches of tags. Als dit in een pipeline gebeurt, kunnen buildtools of scripts falen. Je kunt de ontbrekende data expliciet ophalen met:

# 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=30Mogelijk gemaakt door

Laat Git alle objecten opnieuw van de remote ophalen

Veelvoorkomende foutmeldingen bij git clone en oplossingen

Naast de bovenstaande problemen die je kunt tegenkomen tijdens git clone, behandelt de volgende tabel andere veelvoorkomende fouten.

Conclusie

Het git clone-commando lijkt op het eerste gezicht simpel, en voor velen volstaat de basis vaak. Maar zoals dit artikel laat zien, is het een fundamentele tool met een brede toepasbaarheid.

We bespraken hoe git clone werkt, verkenden URL-typen en protocollen, namen geavanceerde configuraties en OS-specifiek gedrag door, en bekeken praktijkscenario’s zoals CI/CD, enterprise-workflows en veelvoorkomende troubleshooting-technieken.

Het afstemmen van git clone op jouw omgeving—of het nu gaat om shallow clones in pipelines, repositorymigraties of grootschalige samenwerking—kan de performance en team efficiëntie aanzienlijk verbeteren. Nu moderne ontwikkelomgevingen steeds complexer en meer gedistribueerd worden, zorgt het beheersen van deze configuraties ervoor dat je Git niet alleen gebruikt, maar het ook effectief inzet.

Kijkend naar de toekomst kunnen de kloonmechanismen van Git verder verbeteren, zoals slimmere partial clones, betere ondersteuning voor grote monorepo’s, en intuïtievere afhandeling van submodules en filters. Naarmate Git evolueert, blijf je met deze verbeteringen up-to-date om sneller en efficiënter te werken op elk systeem en elke schaal.

Wil je meer leren over Git, dan raad ik aan om de cursus Introduction to Git te volgen. Wil je je skills naar een hoger niveau tillen, dan is de cursus Advanced Git iets voor jou!