git-bundle(1)

NAMN

git-bundle - Flytta objekt och referenser med arkiv

SYNOPSIS

git bundle create [-q | --quiet | --progress]

                     [--version=<version>] <fil> <git-rev-list-args>

git bundle verify [-q | --quiet] <fil> git bundle list-heads <fil> [<refnamn>...] git bundle unbundle [--progress] <fil> [<refnamn>...]

BESKRIVNING

Skapa, packa upp och hantera "bundle"-filer. Bundles används för "offline"-överföring av Git-objekt utan en aktiv "server" på andra sidan nätverksanslutningen.

De kan användas för att skapa både inkrementella och fullständiga säkerhetskopior av ett arkiv (se exemplet "fullständig säkerhetskopiering" i "EXEMPEL"), och för att vidarebefordra tillståndet för referenserna i ett arkiv till ett annat (se det andra exemplet).

Git-kommandon som hämtar eller på annat sätt "läser" via protokoll som ssh:// och https:// kan också fungera på bundle-filer. Det är möjligt att git-clone(1) ett nytt arkiv från en bundle, att använda git-fetch(1) för att hämta från en, och att lista referenserna som finns i den med git-ls-remote(1). Det finns inget motsvarande "skriv"-stöd, dvs. en git push in i en bundle stöds inte.

BUNDLE-FORMAT

Bundles är .pack-filer (se git-pack-objects(1)) med ett huvud som indikerar vilka referenser som finns i bundlen.

Liksom själva det packade arkivformatet kan bundles antingen vara självständiga eller skapas med hjälp av exkluderingar. Se avsnittet "OBJEKTFÖRUTSÄTTNINGAR" nedan.

Bundles som skapats med hjälp av revisionsundantag är "tunna pack" som skapats med alternativet --thin till git-pack-objects(1), och uppackade med alternativet --fix-thin till git-index-pack(1).

Det finns inget alternativ för att skapa en "tjock pack" när man använder revisionsundantag, och användare bör inte oroa sig för skillnaden. Genom att använda "tunna pack" är bundles som skapats med undantag mindre i storlek. Att de är "tunna" under huven noteras här endast som en kuriositet och som en referens till annan dokumentation.

Se gitformat-bundle(5) för mer information och diskussionen om "tunn pack" i gitformat-pack(5) för ytterligare detaljer.

ALTERNATIV

• create [alternativ] <fil> <git-rev-list-args>

Används för att skapa en bundle med namnet fil. Detta kräver

argumenten <git-rev-list-args> för att definiera bundle-innehållet. alternativ innehåller de alternativ som är specifika för underkommandot git bundle create. Om fil är - skrivs bundlen till stdout.

• verify <fil>

Används för att kontrollera att en bundle-fil är giltig och kommer

att tillämpas rent på det aktuella arkivet. Detta inkluderar kontroller av själva bundle-formatet samt kontroll av att de förutsatta commiterna existerar och är fullständigt länkade i det aktuella arkivet. Sedan skriver git bundle ut en lista över eventuella saknade commits. Slutligen skrivs information om ytterligare funktioner, såsom "objektfilter", ut. Se "Capabilities" i gitformat-bundle(5) för mer information. Returkoden är noll vid framgång, men kommer att vara nollskild om bundle-filen är

ogiltig. Om fil är - läses bundlen från stdin.

• list-heads <fil> [<refnamn>...]

Listar de referenser som definieras i bundlen. Om det följs av en

lista med referenser skrivs endast referenser som matchar de givna ut. Om fil är - läses bundlen från stdin.

• unbundle <fil>

Skickar objekten i bundlen till git index-pack för lagring i

arkivet och skriver sedan ut namnen på alla definierade referenser. Om en lista med referenser anges skrivs endast referenser som matchar de i listan ut. Detta kommando är egentligen ett grundläggande kommando, avsett att endast anropas av git fetch. Om fil är - läses bundlen från stdin.

• <git-rev-list-args>

En lista med argument, acceptabla för git rev-parse och git

rev-list (och som innehåller en namngiven referens, se SPECIFIERA REFERENSER nedan), som specificerar de specifika objekt och referenser som ska transporteras. Till exempel, master~10..master gör att den aktuella master-referensen packas tillsammans med alla objekt som lagts till sedan dess tionde förfäders-commit. Det finns ingen explicit gräns för antalet referenser och objekt som kan packas.

• [<refnamn>...]

En lista med referenser som används för att begränsa de referenser

som rapporteras som tillgängliga. Detta är huvudsakligen användbart för git fetch, som förväntar sig att endast ta emot de referenser som begärts och inte nödvändigtvis allt i packet (i detta fall fungerar git bundle som git fetch-pack).

• --progress

Förloppsstatus rapporteras som standard på standardfelströmmen när

den är ansluten till en terminal, om inte -q anges. Denna flagga

tvingar fram förloppsstatus även om standardfelströmmen inte är
riktad till en terminal.

• --version=<version>

Ange bundle-versionen. Version 2 är det äldre formatet och kan

endast användas med SHA-1-arkiv; den nyare version 3 innehåller funktioner som tillåter tillägg. Standard är det äldsta format som stöds, baserat på den hash-algoritm som används.

• -q, --quiet

Denna flagga gör att kommandot inte rapporterar sitt förlopp på

standardfelströmmen.

SPECIFIERA REFERENSER

Revisioner måste åtföljas av referensnamn för att packas i en bundle. Alternativt kan --all användas för att packa alla referenser.

Mer än en referens kan packas, och mer än en uppsättning förutsatta objekt kan specificeras. De objekt som packas är de som inte finns i unionen av förutsättningarna.

Kommandot git bundle create löser referensnamnen åt dig med samma regler som git rev-parse --abbrev-ref=loose. Varje förutsättning kan specificeras explicit (t.ex. ^master~10) eller implicit (t.ex. master~10..master, --since=10.days.ago master).

Alla dessa enkla fall är OK (förutsatt att vi har en "master"- och en "next"-gren):

   $ git bundle create master.bundle master
   $ echo master | git bundle create master.bundle --stdin
   $ git bundle create master-and-next.bundle master next
   $ (echo master; echo next) | git bundle create master-and-next.bundle --stdin

Och det är dessa också (och samma men utelämnade --stdin-exempel):

   $ git bundle create recent-master.bundle master~10..master
   $ git bundle create recent-updates.bundle master~10..master next~5..next

Ett revisionsnamn eller ett intervall vars högra sida inte kan lösas till en referens accepteras inte:

   $ git bundle create HEAD.bundle $(git rev-parse HEAD)
   fatal: Refusing to create empty bundle.
   $ git bundle create master-yesterday.bundle master~10..master~5
   fatal: Refusing to create empty bundle.

OBJEKTFÖRUTSÄTTNINGAR

När man skapar bundles är det möjligt att skapa en självständig bundle som kan packas upp i ett arkiv utan gemensam historik, samt att tillhandahålla negativa revisioner för att exkludera objekt som behövs i de tidigare delarna av historiken.

Att mata en revision som new till git bundle create skapar en bundle-fil som innehåller alla objekt som kan nås från revisionen new. Denna bundle kan packas upp i vilket arkiv som helst för att erhålla en fullständig historik som leder till revisionen new:

   $ git bundle create full.bundle new

Ett revisionsintervall som old..new kommer att producera en bundle-fil som kräver att revisionen old (och alla objekt som kan nås från den) existerar för att bundlen ska kunna "unbundle"-as:

   $ git bundle create full.bundle old..new

En självständig bundle utan några förutsättningar kan extraheras var som helst, även i ett tomt arkiv, eller klonas från (dvs. new, men inte old..new).

Det är OK att vara försiktig och låta bundle-filen innehålla objekt som redan finns på destinationen, eftersom dessa ignoreras vid uppackning på destinationen.

Om du vill tillhandahålla samma uppsättning referenser som en klon direkt från källarkivet skulle få, använd --branches --tags för <git-rev-list-args>.

Kommandot git bundle verify kan användas för att kontrollera om ditt mottagararkiv har de nödvändiga förutsatta commiterna för en bundle.

EXEMPEL

Vi kommer att diskutera två fall:

1. Ta en fullständig säkerhetskopia av ett arkiv
2. Överföra historiken för ett arkiv till en annan maskin när de två
   maskinerna inte har någon direkt anslutning

Först ska vi betrakta en fullständig säkerhetskopia av arkivet. Följande kommando kommer att ta en fullständig säkerhetskopia av arkivet i den meningen att alla referenser inkluderas i bundlen:

   $ git bundle create backup.bundle --all

Men observera återigen att detta endast gäller referenserna, dvs. du kommer endast att inkludera referenser och commits som kan nås från dessa referenser. Du kommer inte att inkludera annat lokalt tillstånd, såsom innehållet i indexet, arbetskopian, stashen, arkivspecifik konfiguration, krokar etc.

Du kan senare återställa det arkivet genom att till exempel använda git-clone(1):

   $ git clone backup.bundle <ny katalog>

För nästa exempel, antag att du vill överföra historiken från ett arkiv R1 på maskin A till ett annat arkiv R2 på maskin B. Av någon anledning är direkt anslutning mellan A och B inte tillåten, men vi kan flytta data från A till B via någon mekanism (CD, e-post etc.). Vi vill uppdatera R2 med utveckling som gjorts på grenen master i R1.

För att starta processen kan du först skapa en bundle som inte har några förutsättningar. Du kan använda en tagg för att komma ihåg upp till vilken commit du senast bearbetade, för att göra det enkelt att senare uppdatera det andra arkivet med en inkrementell bundle:

   maskinA$ cd R1
   maskinA$ git bundle create file.bundle master
   maskinA$ git tag -f lastR2bundle master

Sedan överför du file.bundle till målmaskinen B. Eftersom denna bundle inte kräver att något befintligt objekt extraheras kan du skapa ett nytt arkiv på maskin B genom att klona från den:

   maskinB$ git clone -b master /home/mig/tmp/file.bundle R2

Detta kommer att definiera en fjärranslutning med namnet "origin" i det resulterande arkivet som låter dig hämta och dra från bundlen. Filen GIT\_DIR/config i R2 kommer att ha en post som denna\: \[remote "origin"\] url \= /home/mig/tmp/file\.bundle fetch \= refs/heads/\*\:refs/remotes/origin/\* För att uppdatera det resulterande mitt\.git\-arkivet kan du hämta eller dra efter att ha ersatt bundlen som lagras på /home/mig/tmp/file\.bundle med inkrementella uppdateringar\. Efter att ha arbetat lite mer i det ursprungliga arkivet kan du skapa en inkrementell bundle för att uppdatera det andra arkivet\: maskinA cd R1

   maskinA$ git bundle create file.bundle lastR2bundle..master
   maskinA$ git tag -f lastR2bundle master

Sedan överför du bundlen till den andra maskinen för att ersätta /home/mig/tmp/file.bundle och drar från den.

   maskinB$ cd R2
   maskinB$ git pull

Om du vet upp till vilken commit det avsedda mottagararkivet bör ha de nödvändiga objekten kan du använda den kunskapen för att specificera förutsättningarna, vilket ger en brytpunkt för att begränsa de revisioner och objekt som hamnar i den resulterande bundlen. I föregående exempel användes taggen lastR2bundle för detta ändamål, men du kan använda alla andra alternativ som du skulle ge till kommandot git-log(1). Här är fler exempel:

Du kan använda en tagg som finns i båda:

   $ git bundle create mybundle v1.0.0..master

Du kan använda en förutsättning baserad på tid:

   $ git bundle create mybundle --since=10.days master

Du kan använda antalet commits:

   $ git bundle create mybundle -10 master

Du kan köra git-bundle verify för att se om du kan extrahera från en bundle som skapades med en förutsättning:

   $ git bundle verify mybundle

Detta kommer att lista vilka commits du måste ha för att kunna extrahera från bundlen och kommer att ge fel om du inte har dem.

En bundle från ett mottagararkivs synvinkel är precis som ett vanligt arkiv som det hämtar eller drar från. Du kan till exempel mappa referenser när du hämtar:

   $ git fetch mybundle master:lokalRef

Du kan också se vilka referenser det erbjuder:

   $ git ls-remote mybundle

DISKUSSION

Ett naivt sätt att göra en fullständig säkerhetskopia av ett arkiv är att använda något i stil med cp -r <arkiv> <destination>. Detta avråds eftersom arkivet kan skrivas till under kopieringen. I sin tur kan vissa filer på <destination> skadas.

Det är därför det rekommenderas att använda Git-verktyg för att göra säkerhetskopior av arkiv, antingen med detta kommando eller med t.ex. git-clone(1). Men kom ihåg att dessa verktyg inte hjälper dig att säkerhetskopiera annat tillstånd än referenser och commits. Med andra ord hjälper de dig inte att säkerhetskopiera innehållet i indexet, arbetskopian, stashen, arkivspecifik konfiguration, krokar etc.

Se även gitfaq(7), avsnitt "TRANSFERS" för en diskussion om de problem som är förknippade med filsynkronisering mellan system.

FILFORMAT

Se gitformat-bundle(5).

GIT

Del av git(1)-sviten

KOLOFON

Den här sidan är en del av projektet git (Git distribuerat versionshanteringssystem). Information om projektet finns på <⟨http://git-scm.com/⟩>. Om du har en felrapport för den här manualsidan, se <⟨http://git-scm.com/community⟩>. Den här sidan hämtades från projektets uppströms Git-arkiv <⟨https://github.com/git/git.git⟩> den 2025-02-02. (Vid den tidpunkten var datumet för den senast hittade commiten i arkivet 2025-01-31.) Om du upptäcker några renderingsproblem i den här HTML-versionen av sidan, eller om du tror att det finns en bättre eller mer aktuell källa för sidan, eller om du har korrigeringar eller förbättringar av informationen i den här KOLOFONEN (som *inte* är en del av den ursprungliga manualsidan), skicka ett e-postmeddelande till man-pages@man7.org

Sidslut

Orginalhemsidan på Engelska https://man7.org/linux/man-pages/man1/git-bundle.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 som har sponsrat Linux.se med webbhotell.