git-clone(1)

NAMN

git-clone — klona ett arkiv till en ny katalog

SYNOPSIS

git clone [--template=<mallkatalog>]
          [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
          [-o <namn>] [-b <namn>] [-u <upload-pack>]
          [--reference <arkiv>] [--dissociate]
          [--separate-git-dir <git-katalog>]
          [--depth <djup>] [--[no-]single-branch] [--[no-]tags]
          [--recurse-submodules[=<pathspec>]]
          [--[no-]shallow-submodules]
          [--[no-]remote-submodules]
          [--jobs <n>] [--sparse] [--[no-]reject-shallow]
          [--filter=<filter-spec> [--also-filter-submodules]]
          [--] <arkiv> [<katalog>]

BESKRIVNING

git clone klonar ett arkiv till en nyskapad katalog, skapar fjärrspårande grenar för varje gren i det klonade arkivet, vilket kan visas med:

git branch --remotes

Kommandot skapar och checkar också ut en första gren som utgår från det klonade arkivets för tillfället aktiva gren.

Efter kloningen kommer ett vanligt:

git fetch

utan argument att uppdatera alla fjärrspårande grenar. Ett vanligt:

git pull

utan argument kommer dessutom att slå ihop fjärrens master-gren med den aktuella lokala master-grenen, om någon sådan finns. Detta gäller inte när --single-branch används.

Denna standardkonfiguration skapas genom att referenser till fjärrens grenhuvuden läggs under:

refs/remotes/origin

och genom att konfigurationsvariablerna remote.origin.url och remote.origin.fetch initieras.

FLAGGOR

-l, --local

När arkivet som ska klonas finns på den lokala maskinen går denna flagga förbi den normala Git-medvetna transportmekanismen och klonar arkivet genom att kopiera HEAD och allt under katalogerna objects och refs.

Filer under katalogen:

.git/objects/

hårdlänkas när det är möjligt för att spara diskutrymme.

Om arkivet anges som en lokal sökväg, till exempel:

/path/to/repo

är detta standardbeteendet, och --local gör i praktiken ingenting. Om arkivet anges som en URL ignoreras denna flagga och de lokala optimeringarna används inte.

Flaggan --no-local kan användas för att åsidosätta standardbeteendet när en lokal sökväg anges, så att den vanliga Git-transporten används i stället.

Om arkivets $GIT_DIR/objects innehåller symboliska länkar, eller själv är en symbolisk länk, misslyckas kloningen. Detta är en säkerhetsåtgärd för att förhindra att filer kopieras oavsiktligt genom att symboliska länkar följs.

Denna flagga fungerar inte med arkiv som ägs av andra användare av säkerhetsskäl. Då måste --no-local anges för att kloningen ska lyckas.

Observera: operationen kan krocka med samtidiga ändringar i källarkivet, ungefär som att köra:

cp -r <källa> <mål>

samtidigt som källan ändras.

--no-hardlinks

Tvinga kloning från ett arkiv på ett lokalt filsystem att kopiera filerna under:

.git/objects

i stället för att använda hårdlänkar. Detta kan vara önskvärt om du försöker göra en säkerhetskopia av arkivet.

-s, --shared

När arkivet som ska klonas finns på den lokala maskinen används inte hårdlänkar. I stället ställs:

.git/objects/info/alternates

in automatiskt så att objekten delas med källarkivet. Det resulterande arkivet börjar utan några egna objekt.

Observera: detta är potentiellt farligt. Använd det inte om du inte förstår vad det gör. Om du klonar ett arkiv med denna flagga och sedan tar bort grenar, eller använder andra Git-kommandon som gör commits orefererade i källarkivet, kan vissa objekt bli orefererade. Dessa objekt kan tas bort av vanliga Git-operationer, till exempel git commit, som automatiskt kan köra:

git maintenance run --auto

Om sådana objekt tas bort och fortfarande refereras av det klonade arkivet, blir det klonade arkivet korrupt.

Om du kör:

git repack

utan flaggan --local i ett arkiv som klonats med --shared, kopieras objekt från källarkivet till ett pack i det klonade arkivet. Det tar bort diskutrymmesvinsten med clone --shared.

Det är däremot säkert att köra:

git gc

eftersom det använder --local som standard.

Om du vill bryta beroendet mellan ett arkiv som klonats med --shared och dess källarkiv kan du köra:

git repack -a

Då kopieras alla objekt från källarkivet till ett pack i det klonade arkivet.

--reference[-if-able] <arkiv>

Om referensarkivet finns på den lokala maskinen ställs:

.git/objects/info/alternates

in automatiskt så att objekt kan hämtas från referensarkivet. Ett redan befintligt arkiv kan då användas som alternativ källa, vilket minskar mängden objekt som behöver kopieras från arkivet som klonas. Detta minskar både nätverkstrafik och lokal lagringsanvändning.

Med --reference-if-able hoppas en icke existerande katalog över med en varning i stället för att avbryta kloningen.

Observera: se även varningen för --shared och flaggan --dissociate.

--dissociate

Låna objekt från referensarkiv som angivits med --reference endast för att minska nätverksöverföringen, och sluta sedan låna från dem efter att kloningen är klar genom att skapa nödvändiga lokala kopior.

Denna flagga kan också användas när man klonar lokalt från ett arkiv som redan lånar objekt från ett annat arkiv. Det nya arkivet kommer då först att låna från samma arkiv, men --dissociate kan användas för att bryta beroendet.

-q, --quiet

Kör tyst. Förloppsinformation skrivs inte till standardfel.

-v, --verbose

Kör med mer utförlig utdata. Detta påverkar inte rapportering av förloppsstatus till standardfel.

--progress

Förloppsstatus rapporteras normalt till standardfel när standardfel är kopplat till en terminal, om inte --quiet anges. Denna flagga tvingar fram förloppsstatus även om standardfel inte går till en terminal.

--server-option=<flagga>

Skicka den angivna strängen till servern vid kommunikation med protokollversion 2. Strängen får inte innehålla NUL- eller LF-tecken.

Hur servern hanterar serverflaggor, inklusive okända flaggor, är serverspecifikt. Om flera --server-option=<flagga> anges skickas de till andra sidan i samma ordning som på kommandoraden.

Om ingen --server-option anges på kommandoraden används i stället värden från konfigurationsvariabeln:

remote.<namn>.serverOption

-n, --no-checkout

Ingen utcheckning av HEAD görs efter att kloningen är färdig.

--[no-]reject-shallow

Misslyckas om källarkivet är ett grunt arkiv. Konfigurationsvariabeln:

clone.rejectShallow

kan användas för att ange standardbeteendet.

--bare

Skapa ett naket Git-arkiv. I stället för att skapa <katalog> och placera de administrativa filerna i:

<katalog>/.git

görs <katalog> själv till $GIT_DIR.

Detta innebär förstås --no-checkout, eftersom det inte finns något arbetsträd att checka ut till.

Grenhuvuden på fjärren kopieras direkt till motsvarande lokala grenhuvuden, utan att mappas till:

refs/remotes/origin/

När denna flagga används skapas varken fjärrspårande grenar eller tillhörande konfigurationsvariabler.

--sparse

Använd sparse-checkout, där endast filer i toppkatalogen först finns närvarande. Kommandot git-sparse-checkout(1) kan användas för att utöka arbetskatalogen efter behov.

--filter=<filter-spec>

Använd funktionen för partiell klon och begär att servern skickar en delmängd av nåbara objekt enligt ett objektfilter.

När --filter används anger <filter-spec> filtret för den partiella klonen.

Exempel:

--filter=blob:none

filtrerar bort alla blobbar, alltså filinnehåll, tills Git behöver dem.

Ett annat exempel:

--filter=blob:limit=<storlek>

filtrerar bort alla blobbar med minst den angivna storleken.

För mer information om filterspecifikationer, se flaggan --filter i git-rev-list(1).

--also-filter-submodules

Använd även filtret för partiell klon på eventuella submoduler i arkivet. Kräver både --filter och --recurse-submodules.

Detta kan aktiveras som standard med konfigurationsflaggan:

clone.filterSubmodules

--mirror

Skapa en spegel av källarkivet. Detta innebär --bare.

Jämfört med --bare mappar --mirror inte bara lokala grenar från källan till lokala grenar i målet. Den mappar alla referenser, inklusive fjärrspårande grenar, notes med mera, och ställer in en refspec-konfiguration så att alla dessa referenser skrivs över av:

git remote update

i målarkivet.

-o <namn>, --origin <namn>

Använd <namn> i stället för fjärrnamnet origin för att hålla reda på uppströmsarkivet.

Detta åsidosätter:

clone.defaultRemoteName

från konfigurationen.

-b <namn>, --branch <namn>

I stället för att låta det nyskapade HEAD peka på den gren som det klonade arkivets HEAD pekar på, peka på grenen <namn>.

I ett icke-naket arkiv är detta den gren som checkas ut.

--branch kan också ta taggar och kopplar då loss HEAD vid den aktuella committen i det resulterande arkivet.

--revision=<rev>

Skapa ett nytt arkiv och hämta historiken som leder fram till den angivna revisionen <rev>, och inget annat. Inga fjärrspårande grenar skapas, ingen lokal gren skapas, och HEAD kopplas loss till <rev>.

Argumentet kan vara ett ref-namn, till exempel:

refs/heads/main
refs/tags/v1.0

som skalas ned till en commit, eller ett hexadecimalt objektnamn.

Denna flagga är inkompatibel med --branch och --mirror.

-u <upload-pack>, --upload-pack <upload-pack>

När arkivet som ska klonas nås via ssh anger denna flagga en annan sökväg än standard till kommandot som körs på andra sidan.

--template=<mallkatalog>

Ange katalogen som mallar ska användas från. Se avsnittet "TEMPLATE DIRECTORY" i git-init(1).

-c <nyckel>=<värde>, --config <nyckel>=<värde>

Sätt en konfigurationsvariabel i det nyskapade arkivet. Detta får effekt direkt efter att arkivet initierats, men före fjärrhistoriken hämtas eller några filer checkas ut.

<nyckel> har samma format som i git-config(1), till exempel:

core.eol=true

Om flera värden anges för samma nyckel skrivs varje värde till konfigurationsfilen. Detta gör det säkert att exempelvis lägga till extra fetch-refspecs för origin-fjärren.

På grund av begränsningar i nuvarande implementation får vissa konfigurationsvariabler ingen effekt förrän efter den första hämtningen och utcheckningen. Variabler som är kända för att inte få effekt direkt är:

remote.<namn>.mirror
remote.<namn>.tagOpt

Använd motsvarande --mirror och --no-tags i stället.

--depth <djup>

Skapa en grund klon med historiken avkortad till angivet antal commits.

Detta innebär --single-branch om inte --no-single-branch anges för att hämta historiken nära topparna för alla grenar.

Om du vill klona submoduler grunt, använd även:

--shallow-submodules

--shallow-since=<datum>

Skapa en grund klon med historik efter angiven tidpunkt.

--shallow-exclude=<ref>

Skapa en grund klon med historik, men uteslut commits som är nåbara från en angiven fjärrgren eller tagg.

Denna flagga kan anges flera gånger.

--single-branch, --no-single-branch

Klona endast historiken som leder till toppen av en enda gren, antingen den som anges med --branch eller den primära gren som fjärrens HEAD pekar på.

Senare hämtningar i det resulterande arkivet kommer endast att uppdatera den fjärrspårande grenen för den gren som användes vid den ursprungliga kloningen.

Om HEAD på fjärren inte pekade på någon gren när --single-branch användes, skapas ingen fjärrspårande gren.

--tags, --no-tags

Styr om taggar ska klonas eller inte.

När --no-tags anges blir flaggan permanent genom att följande konfiguration sätts:

remote.<fjärr>.tagOpt=--no-tags

Detta gör att framtida git pull och git fetch inte följer taggar. Explicit hämtning av taggar fungerar fortfarande, se git-fetch(1).

Som standard klonas taggar, och --tags är därför normalt en no-op, om den inte upphäver en tidigare --no-tags.

Flaggan kan användas tillsammans med --single-branch för att klona och underhålla en gren utan andra referenser än den enda klonade grenen. Detta är användbart till exempel för minimala kloner av standardgrenen i ett arkiv för sökindexering.

--recurse-submodules[=<pathspec>]

Efter att klonen skapats initieras och klonas submoduler enligt angiven <pathspec>.

Om ingen <pathspec> anges initieras och klonas alla submoduler. Flaggan kan anges flera gånger för pathspecs med flera poster.

Den resulterande klonen får:

submodule.active

satt till angiven pathspec, eller "." om ingen pathspec anges, vilket betyder alla submoduler.

Submoduler initieras och klonas med sina standardinställningar. Detta motsvarar att köra:

git submodule update --init --recursive <pathspec>

direkt efter att kloningen är klar.

Flaggan ignoreras om det klonade arkivet inte har ett arbetsträd eller en utcheckning, det vill säga om någon av följande flaggor används:

--no-checkout
-n
--bare
--mirror

--shallow-submodules, --no-shallow-submodules

Alla submoduler som klonas blir grunda med djupet 1.

--remote-submodules, --no-remote-submodules

Alla submoduler som klonas använder submodulens fjärrspårande gren för uppdatering, i stället för SHA-1-värdet som superprojektet anger.

Det motsvarar att skicka:

--remote

till:

git submodule update

--separate-git-dir=<git-katalog>

I stället för att placera det klonade arkivet där det normalt ska ligga, placeras Git-arkivet i den angivna katalogen. Därefter skapas en filsystemsoberoende Git-symbolisk länk dit.

Resultatet är att Git-arkivet kan separeras från arbetsträdet.

--ref-format=<ref-format>

Ange lagringsformatet för referenser i arkivet.

Giltiga värden är:

files

För lösa filer med packed-refs. Detta är standard.

reftable

För reftable-formatet. Detta format är experimentellt och dess interna struktur kan ändras.

-j <n>, --jobs <n>

Antalet submoduler som hämtas samtidigt. Standardvärdet kommer från:

submodule.fetchJobs

<arkiv>

Det, eventuellt fjärrbaserade, arkiv som ska klonas från. Se avsnittet GIT-URL:ER nedan för mer information om hur arkiv anges.

<katalog>

Namnet på en ny katalog att klona till.

Den "människoläsbara" delen av källarkivet används om ingen <katalog> anges uttryckligen. Exempel:

repo

för:

/path/to/repo.git

och:

foo

för:

host.xz:foo/.git

Kloning till en befintlig katalog är endast tillåten om katalogen är tom.

--bundle-uri=<uri>

Innan hämtning från fjärren sker hämtas en bundle från angiven <uri> och packas upp i det lokala arkivet.

Referenserna i bundlen lagras under det dolda namnområdet:

refs/bundle/*

Denna flagga är inkompatibel med:

--depth
--shallow-since
--shallow-exclude

GIT-URL:ER

I allmänhet innehåller URL:er information om transportprotokoll, adressen till fjärrservern och sökvägen till arkivet. Beroende på transportprotokoll kan delar av denna information saknas.

Git stöder protokollen ssh, git, http och https. Dessutom kan ftp och ftps användas för hämtning, men detta är ineffektivt och föråldrat. Använd dem inte.

Följande syntaxer kan användas:

ssh://[<användare>@]<värd>[:<port>]/<sökväg-till-git-arkiv>
git://<värd>[:<port>]/<sökväg-till-git-arkiv>
http[s]://<värd>[:<port>]/<sökväg-till-git-arkiv>
ftp[s]://<värd>[:<port>]/<sökväg-till-git-arkiv>

En alternativ scp-liknande syntax kan också användas med ssh-protokollet:

[<användare>@]<värd>:/<sökväg-till-git-arkiv>

Denna syntax känns bara igen om det inte finns några snedstreck före det första kolontecknet. Detta hjälper Git att skilja från en lokal sökväg som innehåller kolon.

Exempel: den lokala sökvägen:

foo:bar

kan anges som en absolut sökväg eller som:

./foo:bar

för att undvika att den misstolkas som en ssh-URL.

ssh- och git-protokollen stöder dessutom expansion med:

~<användarnamn>

Exempel:

ssh://[<användare>@]<värd>[:<port>]/~<användare>/<sökväg-till-git-arkiv>
git://<värd>[:<port>]/~<användare>/<sökväg-till-git-arkiv>
[<användare>@]<värd>:~<användare>/<sökväg-till-git-arkiv>

För lokala arkiv, som också stöds direkt av Git, kan följande syntaxer användas:

/path/to/repo.git/
file:///path/to/repo.git/

Dessa två syntaxer är i stort sett likvärdiga, förutom att den första innebär flaggan --local.

git clone, git fetch och git pull, men inte git push, accepterar även en lämplig bundle-fil. Se git-bundle(1).

När Git inte vet hur ett visst transportprotokoll ska hanteras försöker Git använda fjärrhjälparen:

remote-<transport>

om en sådan finns.

För att uttryckligen begära en fjärrhjälpare kan följande syntax användas:

<transport>::<adress>

där <adress> kan vara en sökväg, en server och sökväg, eller en godtycklig URL-liknande sträng som förstås av den specifika fjärrhjälparen. Se gitremote-helpers(7) för detaljer.

Om det finns många fjärrarkiv med liknande namn och du vill använda ett annat format för dem, så att URL:erna skrivs om till URL:er som fungerar, kan du skapa en konfigurationssektion av formen:

[url "<faktisk-url-bas>"]
        insteadOf = <annan-url-bas>

Exempel:

[url "git://git.host.xz/"]
        insteadOf = host.xz:/path/to/
        insteadOf = work:

Då skrivs en URL som:

work:repo.git

eller:

host.xz:/path/to/repo.git

om till:

git://git.host.xz/repo.git

i alla sammanhang där en URL används.

Om du vill skriva om URL:er endast för push kan du skapa en konfigurationssektion av formen:

[url "<faktisk-url-bas>"]
        pushInsteadOf = <annan-url-bas>

Exempel:

[url "ssh://example.org/"]
        pushInsteadOf = git://example.org/

Då skrivs en URL som:

git://example.org/path/to/repo.git

om till:

ssh://example.org/path/to/repo.git

för push, men pull använder fortfarande den ursprungliga URL:en.

EXEMPEL

Klona från uppströms:

$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
$ cd my-linux
$ make

Skapa en lokal klon som lånar från aktuell katalog, utan att checka ut filer:

$ git clone -l -s -n . ../copy
$ cd ../copy
$ git show-branch

Klona från uppströms och låna samtidigt från en befintlig lokal katalog:

$ git clone --reference /git/linux.git \
        git://git.kernel.org/pub/scm/.../linux.git \
        my-linux
$ cd my-linux

Skapa ett naket arkiv för att publicera dina ändringar offentligt:

$ git clone --bare -l /home/proj/.git /pub/scm/proj.git

Klona ett lokalt arkiv från en annan användare:

$ git clone --no-local /home/otheruser/proj.git /pub/scm/proj.git

KONFIGURATION

Allt nedan i detta avsnitt är selektivt inkluderat från dokumentationen för git-config(1). Innehållet är detsamma som där.

init.templateDir

Ange katalogen som mallar ska kopieras från. Se avsnittet "TEMPLATE DIRECTORY" i git-init(1).

init.defaultBranch

Tillåter att standardnamnet på grenen åsidosätts, till exempel när ett nytt arkiv initieras.

init.defaultObjectFormat

Tillåter att standardformatet för objekt i nya arkiv åsidosätts. Se --object-format= i git-init(1).

Både kommandoradsflaggan och miljövariabeln:

GIT_DEFAULT_HASH

har företräde framför denna konfiguration.

init.defaultRefFormat

Tillåter att standardformatet för referenslagring i nya arkiv åsidosätts. Se --ref-format= i git-init(1).

Både kommandoradsflaggan och miljövariabeln:

GIT_DEFAULT_REF_FORMAT

har företräde framför denna konfiguration.

clone.defaultRemoteName

Namnet på fjärren som skapas vid kloning av ett arkiv. Standardvärdet är:

origin

Det kan åsidosättas med kommandoradsflaggan --origin.

clone.rejectShallow

Avvisa kloning av ett arkiv om det är grunt. Detta kan åsidosättas med flaggan --reject-shallow på kommandoraden.

clone.filterSubmodules

Om ett filter för partiell klon anges, se --filter i git-rev-list(1), och --recurse-submodules används, ska filtret även tillämpas på submoduler.

GIT

Ingår i git(1)-sviten.

COLOPHON

Denna sida är en del av projektet git — det distribuerade versionshanteringssystemet Git.

Information om projektet finns på:

http://git-scm.com/

Om du har en felrapport för denna manualsida, se:

http://git-scm.com/community

Denna sida hämtades från projektets uppströms Git-arkiv: https://github.com/git/git.git den 16 januari 2026.

Vid den tidpunkten var datumet för den senaste commit som hittades i arkivet den 15 januari 2026.

Om du upptäcker renderingsproblem i denna HTML-version av sidan, eller om du anser att det finns en bättre eller mer uppdaterad källa för sidan, eller om du har rättelser eller förbättringar av informationen i detta COLOPHON-avsnitt, som inte är en del av den ursprungliga manualsidan, skicka e-post till:

man-pages@man7.org

Git 2.53.0.rc0 2026-01-15 GIT-CLONE(1)

Sidslut

Orginalhemsidan på Engelska https://man7.org/linux/man-pages/man1/git-clone.1.html Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på https://www.linux.se/kontaka-linux-se/

Tack till Datorhjälp hemma som har sponsrat Linux.se med webbhotell.