Tag backup af et GitHub-repository – LFS kræver et ekstra trin

|Forfatter: QUASA's redaktion|4 min. læsning
Tag backup af et GitHub-repository – LFS kræver et ekstra trin

GitHubs backupvejledning bruger en spejlklon til repositoryets Git-historik og angiver et særskilt git lfs fetch --all, hvis projektet bruger Git LFS. Gem først kopien, når begge dele er hentet. Ellers kan Git-historikken gendannes, mens indholdet bag LFS-filerne mangler.

Et fuldt Git-bundle er et alternativ, når Git-historikken skal flyttes som én fil. Gits bundle-dokumentation beskriver både oprettelse, verifikation og kloning fra filen. Bundlet indeholder ikke LFS-objekterne, så et projekt med LFS kræver et tilhørende arkiv og en prøvegendannelse af begge dele.

Spejlklon: Gem Git og LFS i samme arkiv

En spejlklon er velegnet, når repositoryets referencer senere skal kunne skubbes til en ny Git-adresse. Erstat BRUGER og PROJEKT med den faktiske ejer og det faktiske repositorynavn. Kør kommandoerne fra den mappe, hvor backupfilerne skal oprettes:

  1. git clone --mirror https://github.com/BRUGER/PROJEKT.git projekt.git
  2. git -C projekt.git lfs fetch --all
  3. tar -czf projekt-spejl.tar.gz projekt.git

Spring kun det midterste trin over, hvis projektet ikke bruger Git LFS. Git LFS skal være installeret, og hentningen skal afsluttes uden fejl, før mappen pakkes. En spejlklon er et bare repository uden arbejdsmappe; det er derfor arkivet med repositorymappen, der er backupen, ikke en udtjekket kopi af projektets filer.

Git LFS gemmer store filers indhold særskilt fra de pointere, der ligger i Git-historikken. Ved at hente LFS-objekterne før komprimeringen kommer det lokale LFS-lager med i spejlarkivet. Hvis repositoryet bruger en ændret placering til LFS-lageret, skal den placering også indgå i backupen; kommandoen ovenfor forudsætter standardplaceringen inde i repositorymappen.

Git-bundle: Flyt Git-historikken som én fil

Et fuldt bundle pakker de referencer og de Git-objekter, der kan nås fra dem, i en fil. Lav det fra en frisk spejlklon, så udgangspunktet er de referencer, kloningen modtog fra GitHub. Gem bundle-filen uden for spejlmappen, og verificér den i et tomt repository:

  1. git clone --mirror https://github.com/BRUGER/PROJEKT.git projekt-kilde.git
  2. git -C projekt-kilde.git bundle create ../projekt.bundle --all
  3. git init --bare tom-kontrol.git
  4. git -C tom-kontrol.git bundle verify ../projekt.bundle
  5. GIT_LFS_SKIP_SMUDGE=1 git clone projekt.bundle proeveklon

Verifikationen i det tomme repository kontrollerer, om bundlet kan bruges uden commits fra en tidligere backup. Det skel er vigtigt, fordi et inkrementelt bundle kan kræve Git-objekter, som kun findes i en ældre kopi. Prøveklonen kontrollerer derudover, at bundlet faktisk kan danne et nyt repository. Hvis projektet bruger LFS, lader GIT_LFS_SKIP_SMUDGE=1 kloningen beholde pointerne under denne Git-kontrol.

Hent derefter LFS-indholdet fra bundle-kildens repository, og gem det som en ledsagende fil: git -C projekt-kilde.git lfs fetch --all efterfulgt af tar -czf projekt-lfs.tar.gz -C projekt-kilde.git lfs/objects. Den sidste kommando forudsætter LFS-lagerets standardplacering. Opbevar projekt.bundle og projekt-lfs.tar.gz som ét backupsæt; bundle-filen kan stå alene som kopi af Git-historikken, men kan ikke alene levere de store filers indhold.

Prøvegendan historikken og de store filer

Pak et spejlarkiv ud i en tom testmappe med tar -xzf projekt-spejl.tar.gz. Kør git -C projekt.git fsck --full for at kontrollere Git-objekterne og git -C projekt.git show-ref for at se de gemte referencer. En almindelig klon fra den udpakkede mappe viser, om den valgte gren kan tjekkes ud; bruger projektet LFS, skal filindholdet også kontrolleres efter gendannelsen.

For bundle-metoden kan git bundle list-heads projekt.bundle sammenholdes med de forventede referencer. Genskab derefter et spejl med git clone --mirror projekt.bundle gendannet.git. Hvis projektet bruger LFS, pak det tilhørende arkiv ud i spejlmappen med tar -xzf projekt-lfs.tar.gz -C gendannet.git, før de store filer skal overføres videre. En vellykket bundle-verifikation alene siger intet om LFS-arkivets indhold.

Vil du afprøve gendannelsen på GitHub, skal du først oprette et nyt, tomt destinationsrepository. GitHubs vejledning om spejling angiver en spejl-push til Git-referencerne og en særskilt git lfs push --all til LFS-objekterne. Kør fra det udpakkede spejl eller det gendannede bundle-spejl git -C projekt.git push --mirror https://github.com/BRUGER/NYT-PROJEKT.git og, ved LFS, git -C projekt.git lfs push --all https://github.com/BRUGER/NYT-PROJEKT.git; erstat projekt.git med gendannet.git for bundle-metoden. Brug en tom destination, fordi spejl-push kan fjerne referencer, som kun findes på destinationen. Klon derefter destinationen normalt, og åbn relevante LFS-filer for at kontrollere, at de indeholder data frem for pointere.

Det, Git-kopien ikke tager med

Afgræns backupen efter det, der faktisk skal kunne gendannes. Spejlklonen og bundlet omfatter Git-historik og referencer, men projektets øvrige tilstand kræver andre kopier:

  • Ikke-committede ændringer, ikke-sporede filer, indeks og stash i udviklernes arbejdsmapper følger ikke med en klon fra GitHub.
  • Lokale Git-hooks og repositoryspecifik konfiguration skal gemmes særskilt, hvis arbejdsgangen afhænger af dem.
  • Issues, pull requests, diskussioner, indstillinger og adgangsrettigheder på GitHub ligger uden for Git-referencerne og kræver en særskilt backup eller eksport.
  • En GitHub-wiki er sit eget Git-repository og skal klones særskilt, hvis den skal kunne gendannes.

Opbevar backupsættet et andet sted end den konto eller maskine, det skal beskytte imod at miste. Gentag prøvegendannelsen, når backup-rutinen ændres, så manglende referencer eller LFS-objekter opdages, mens den oprindelige kilde stadig er tilgængelig.

Læs også:

Del:

Relaterede artikler

Tilmeld dig vores nyhedsbrev

Få de seneste nyheder om Web3, AI og krypto direkte i din indbakke.

0