Svenska ▾ Topics ▾ Latest version ▾ git-bundle last updated in 2.48.0

NAMN

git-bundle - Flytta objekt och referenser via 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 <file> [<refnamn>…​]
git bundle unbundle [--progress] <file> [<refnamn>…​]

BESKRIVNING

Skapa, packa upp och manipulera "bundle"-filer. Buntar 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 stegvisa och fullständiga säkerhetskopior av ett arkiv (se exemplet "fullständig säkerhetskopia" i "EXEMPEL"), och för att vidarebefordra statusen för referenserna i ett förvar 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å buntfiler. Det är möjligt git-clone[1] att skapa ett nytt förvar från ett bunt, att använda git-fetch[1] för att hämta från ett, och att lista referenserna i det med git-ls-remote[1]. Det finns inget motsvarande "skriv"-stöd, d.v.s. en git push in i en bunt stöds inte.

BUNTFORMAT

Buntar är .pack-filer (se git-pack-objects[1]) med en rubrik som anger vilka referenser som finns i bunten.

Precis som det packade arkiv-formatet kan buntar antingen vara fristående eller skapas med hjälp av exkluderingar. Se avsnittet "OBJEKT-FÖRUTSÄTTNINGAR" nedan.

Buntar som skapas med hjälp av revisions-exkluderingar är "tunna paket" som skapas med hjälp av alternativet --thin till git-pack-objects[1], och packas upp med hjälp av alternativet --fix-thin till git-index-pack[1].

Det finns inget alternativ att skapa ett "tjockt paket" när man använder revisions-exkluderingar, och användare bör inte oroa sig för skillnaden. Genom att använda "tunna paket" blir paket som skapas med undantag mindre i storlek. Att de är "tunna" under huven noteras här endast som en kuriositet och som en hänvisning till annan dokumentation.

Se gitformat-bundle[5] för mer information och diskussionen om "tunna paket" i gitformat-pack[5] för ytterligare information.

ALTERNATIV

create [flaggor] <fil> <git-rev-list-args>

Används för att skapa ett buntar med namnet fil. Detta kräver argumenten <git-rev-list-args> för att definiera paketets innehåll. flaggor innehåller de alternativ som är specifika för underkommandot git bundle create. Om fil är - skrivs paketet till stdout.

verify <fil>

Används för att kontrollera att en bunt-fil är giltig och kommer att tillämpas korrekt på det aktuella förvaret. Detta inkluderar kontroller av själva bunt-formatet samt kontroll av att nödvändiga incheckningar finns och är fullständigt länkade i det aktuella förvaret. Sedan skriver git bundle ut en lista över eventuella saknade incheckningar. Slutligen skrivs information om ytterligare funktioner, såsom "objektfilter", ut. Se "Förmågor" i gitformat-bundle[5] för mer information. Avslutningskoden är noll för att lyckas, men kommer att vara annan än noll om bunt-filen är ogiltig. Om fil är - läses bundle-filen från stdin.

list-heads <fil>

Listar referenserna som definierats i bunten. Om det följs av en lista med referenser, skrivs endast referenser som matchar de angivna ut. Om fil är - läses bunten från stdin.

unbundle <fil>

Skickar objekten i bunten till git index-pack för lagring i förvaret 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 rörmokeri-kommando, avsett att anropas endast av git fetch. Om fil är - läses paketet från stdin.

<git-rev-list-args>

En lista med argument, acceptabla för git rev-parse och git rev-list (och innehållande en namngiven referens, se SPECIFIERING AV REFERENSER nedan), som anger de specifika objekten och referenserna som ska transporteras. Till exempel gör master~10..master att den aktuella master-referensen paketeras tillsammans med alla objekt som lagts till sedan dess 10:e förfader-incheckningen. Det finns ingen uttrycklig gräns för antalet referenser och objekt som kan paketeras.

[<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 efterfrågas och inte nödvändigtvis allt i paketet (i det här fallet fungerar git bundle som git fetch-pack).

--progress

Förloppsstatus rapporteras som standard i standardfelströmmen när den är kopplad till en terminal, såvida inte -q anges. Denna flagga tvingar fram förloppsstatus även om standardfelströmmen inte dirigeras till en terminal.

--version=<version>

Ange bunt-versionen. Version 2 är det äldre formatet och kan endast användas med SHA-1-arkiv; den nyare versionen 3 innehåller funktioner som tillåter tillägg. Standardinställningen är det äldsta formatet som stöds, baserat på den hashalgoritm som används.

-q
--quiet

Denna flagga gör att kommandot inte rapporterar sina förlopp i standardfelströmmen.

SPECIFIERING AV REFERENSER

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

More than one reference may be packaged, and more than one set of prerequisite objects can be specified. The objects packaged are those not contained in the union of the prerequisites.

Kommandot git bundle create löser referensnamnen åt dig med samma regler som git rev-parse --abbrev-ref=loose. Varje förutsättning kan anges 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-och-next.bundle --stdin

Och så är dessa (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 upp 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.

OBJECT PREREQUISITES

När man skapar buntar är det möjligt att skapa ett fristående bunt som kan delas upp i ett förvar 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 ny till git bundle create skapar en bunt-fil som innehåller alla objekt som kan nås från revisionen ny. Den bunten kan packas upp i vilket förvar som helst för att få en fullständig historik som leder till revisionen ny:

$ git bundle create full.bundle ny

Ett revisions-intervall som gammal..ny kommer att producera en bunt-fil som kräver att revisionen old (och alla objekt som kan nås från den) finns för att paketet ska kunna "avbuntas":

$ git bundle create full.bundle gammal..ny

Ett fristående bunt utan några förkrav kan extraheras var som helst, även till ett tomt arkiv, eller klonas från (dvs. nytt, men inte gammalt..ny).

Det är okej att vara på den försiktiga sidan, och orsaka att bunt-filen innehåller objekt som redan finns i destinationen, eftersom dessa ignoreras vid uppackning i destinationen.

Om du vill tillhandahålla samma uppsättning referenser som en klon direkt från käll-förrådet 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 mottagar-förråd har de nödvändiga incheckningar för en bunt.

EXEMPEL

Vi kommer att diskutera två fall:

  1. Att ta en fullständig säkerhetskopia av ett förråd

  2. Överföra historiken för ett förråd till en annan maskin när de två maskinerna inte har någon direkt anslutning

Låt oss först överväga en fullständig säkerhetskopia av förrådet. Följande kommando kommer att göra en fullständig säkerhetskopia av förrådet i den meningen att alla referenser ingår i bunten:

$ git bundle create backup.bundle --all

Men observera återigen att detta endast gäller för referenserna, d.v.s. du kommer endast att inkludera referenser och incheckningar som är åtkomliga från dessa referenser. Du kommer inte att inkludera andra lokala tillstånd, såsom innehållet i indexet, arbetskatalogen, gömman, konfiguration per förvar, krokar, etc.

Du kan senare återställa det förvaret genom att till exempel använda git-clone[1]:

$ git clone backup.bundle <new directory>

I nästa exempel, anta att du vill överföra historiken från ett förvar R1 på maskin A till ett annat förvar 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 gjord på grenen master i R1.

För att starta upp processen, kan du först skapa en bunt som inte har några förutsättningar. Du kan använda en tagg för att komma ihåg fram till vilken incheckning du senast bearbetade, för att göra det enkelt att senare uppdatera det andra förvaret med ett inkrementellt paket:

maskinA$ cd R1
maskinA$ git bundle create fil.bundle master
maskinA$ git tag -f senasteR2bunt master

Sedan överför du fil.bundle till målmaskin B. Eftersom detta bunt inte kräver att något befintligt objekt extraheras, kan du skapa ett nytt förvar på maskin B genom att klona från det:

maskinB$ git clone -b master /home/mej/tmp/fil.bundle R2

Detta kommer att definiera en fjärrkontroll som heter "origin" i det resulterande arkivet som låter dig hämta och pull från paketet. Filen $GIT_DIR/config i R2 kommer att ha en post som denna:

[remote "origin"]
    url = /home/mej/tmp/fil.bundle
    fetch = refs/heads/*:refs/remotes/origin/*

To update the resulting mine.git repository, you can fetch or pull after replacing the bundle stored at /home/me/tmp/file.bundle with incremental updates.

Efter att ha arbetat lite mer i det ursprungliga förvaret kan du skapa en stegvis bunt för att uppdatera det andra arkivet:

maskinA$ cd R1
maskinA$ git bundle create fil.bundle senasteR2bunt..master
maskinA$ git tag -f senasteR2bunt master

Sedan överför du bunten till den andra maskinen för att ersätta /home/mej/tmp/fil.bundle, och hämtar från det.

maskinB$ cd R2
maskinB$ git pull

Om du vet upp till vilken incheckning det avsedda mottagar-förrådet ska ha de nödvändiga objekten, kan du använda den kunskapen för att specificera förutsättningarna och ange en gräns för att begränsa revisionerna och objekten som ingår i det resulterande paketet. Det föregående exemplet använde taggen senasteR2bunten för detta ändamål, men du kan använda 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 minbunt v1.0.0..master

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

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

Du kan använda antalet incheckningar:

$ git bundle create minbunt -10 master

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

$ git bundle verify minbunt

Detta listar vilka incheckningar du måste ha för att extrahera från bunten och kommer att ge ett felmeddelande om du inte har dem.

Ett paket, ur ett mottagar-förvars synvinkel, är precis som ett vanligt förvar som det hämtar eller hämtar från. Du kan till exempel mappa referenser när du hämtar:

$ git fetch minbunt master:localRef

Du kan också se vilka referenser den erbjuder:

$ git ls-remote minbunt

DISKUSSION

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

Det är därför det rekommenderas att använda Git-verktyg för att göra säkerhetskopior av förvar, 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 tillstånd förutom referenser och incheckningar. Med andra ord kommer de inte att hjälpa dig att säkerhetskopiera innehållet i indexet, arbetskatalogen, gömman, konfigurationen per arkiv, krokar, etc.

Se även gitfaq[7], avsnittet "ÖVERFÖRINGAR" för en diskussion om problemen i samband med filsynkronisering mellan system.

FILFORMAT

Se gitformat-bundle[5].

GIT

En del av git[1]-sviten