Czy istnieje prosty sposób na wykonanie kopii zapasowej całego repozytorium git, w tym wszystkich gałęzi i tagów?

A co powiesz na zrobienie z tego klonu?

git clone --mirror other/repo.git

Każde repozytorium jest kopią zapasową swojego zdalnego.

git bundle

Podoba mi się ta metoda, ponieważ daje tylko jeden plik, łatwiejszy do skopiowania.
Zobacz ProGit: mały pakiet radości .
Zobacz także „ Jak mogę wysłać komuś wiadomość e-mail z repozytorium git? ”, Gdzie znajduje się polecenie

git bundle create /tmp/foo-all --all

jest szczegółowy:

git bundlezapakuje tylko referencje, które są pokazywane przez git show-ref : obejmuje to głowice, tagi i zdalne głowice.
Bardzo ważne jest, aby podstawa była w posiadaniu miejsca docelowego.
Nie ma nic złego w zachowaniu ostrożności, ponieważ plik pakunku zawiera obiekty już w miejscu docelowym, ponieważ są one ignorowane podczas rozpakowywania w miejscu docelowym.

Aby użyć tego pakietu, możesz go sklonować, określając nieistniejący folder (poza jakimkolwiek repozytorium git):

git clone /tmp/foo-all newFolder

Rozwijając kilka innych odpowiedzi, robię to:

Skonfiguruj repozytorium: git clone --mirror user@server:/url-to-repo.git

Następnie, gdy chcesz odświeżyć kopię zapasową: git remote updatez lokalizacji klonowania.

To tworzy kopię zapasową wszystkich gałęzi i tagów, w tym nowych, które zostaną dodane później, chociaż warto zauważyć, że gałęzie, które są usuwane, nie są usuwane z klonu (co w przypadku kopii zapasowej może być dobrą rzeczą).

To jest atomowe, więc nie ma problemów, jakie miałaby zwykła kopia.

Zobacz http://www.garron.me/en/bits/backup-git-bare-repo.html

Poszerzenie o świetne odpowiedzi KingCrunch i VonC

Połączyłem je oba:

git clone --mirror git@some.origin/reponame reponame.git
cd reponame.git
git bundle create reponame.bundle --all

Następnie masz plik o nazwie, reponame.bundlektóry można łatwo skopiować. Następnie możesz utworzyć nowe normalne repozytorium git na podstawie tego za pomocą git clone reponame.bundle reponame.

Zauważ, że git bundlekopiuje tylko zatwierdzenia, które prowadzą do jakiegoś odniesienia (gałęzi lub tagu) w repozytorium. Tak więc splątane zatwierdzenia nie są przechowywane w pakiecie.

Wszystko jest zawarte w .gitkatalogu. Po prostu wykonaj kopię zapasową wraz z projektem, tak jak w przypadku każdego innego pliku.

użyj pakietu git lub klonuj

kopiowanie katalogu git nie jest dobrym rozwiązaniem, ponieważ nie jest on atomowy. Jeśli masz duże repozytorium, którego kopiowanie zajmuje dużo czasu, a ktoś do niego przesyła, wpłynie to na twoją kopię zapasową. Klonowanie lub tworzenie pakietu nie spowoduje tego problemu.

Możesz wykonać kopię zapasową repozytorium git za pomocą git-copy przy minimalnym rozmiarze magazynu.

git copy /path/to/project /backup/project.repo.backup

Następnie możesz przywrócić projekt za pomocą git clone

git clone /backup/project.repo.backup project

Prawidłowa odpowiedź IMO to git clone --mirror . Spowoduje to pełne wykonanie kopii zapasowej repozytorium.

Git clone mirror sklonuje całe repozytorium, notatki, nagłówki, referencje itp. I jest zwykle używany do kopiowania całego repozytorium na nowy serwer git. Spowoduje to zniszczenie wszystkich gałęzi i wszystkiego, całego repozytorium.

git clone --mirror git@example.com/your-repo.git

• Zwykle klonowanie repozytorium nie obejmuje wszystkich gałęzi, tylko Master.

• Skopiowanie folderu repozytorium spowoduje "skopiowanie" tylko tych gałęzi, które zostały ściągnięte ... więc domyślnie jest to tylko gałąź główna lub inne gałęzie, które wcześniej wyrejestrowałeś.

• Polecenie pakietu Git również nie jest tym, czego chcesz: „Polecenie bundle spakuje wszystko, co normalnie byłoby przekazane za pomocą polecenia git push, do pliku binarnego, który możesz wysłać do kogoś pocztą e-mail lub umieścić na dysku flash, a następnie rozpakuj do innego repozytorium. " (Od Jaka jest różnica między git clone --mirror i git clone --bare )

Ten wątek był bardzo pomocny, aby uzyskać wgląd w sposób tworzenia kopii zapasowych repozytoriów git. Myślę, że wciąż brakuje wskazówek, informacji czy wniosków, aby znaleźć „właściwą drogę” (tm) dla siebie. Dlatego dzielę się tutaj moimi przemyśleniami, aby pomóc innym i poddać je dyskusji, aby je wzmocnić. Dzięki.

A więc zaczynając od odpowiedzi na pierwotne pytanie:

• Celem jest jak największe zbliżenie się do „pełnej” kopii zapasowej repozytorium git.

Następnie wzbogacając go o typowe życzenia i określając niektóre ustawienia wstępne:

• Preferowane jest tworzenie kopii zapasowych „na gorąco”, aby uniknąć przestojów usług.
• Wady gita zostaną omówione przez dodatkowe polecenia.
• Skrypt powinien wykonać kopię zapasową, aby połączyć wiele kroków dla jednej kopii zapasowej i uniknąć błędów ludzkich (literówki itp.).
• Dodatkowo skrypt powinien wykonać przywracanie w celu dostosowania zrzutu do maszyny docelowej, np. Nawet konfiguracja oryginalnej maszyny mogła ulec zmianie od czasu utworzenia kopii zapasowej.
• Środowisko to serwer git na komputerze z systemem Linux z systemem plików obsługującym twarde łącza.

1. Co to jest „pełna” kopia zapasowa repozytorium git?

Punkt widzenia różni się od tego, czym jest kopia zapasowa „100%”. Oto dwa typowe.

# 1 Punkt widzenia programisty

• Zadowolony
• Bibliografia

git to narzędzie programistyczne, które obsługuje ten punkt widzenia za pośrednictwem git clone --mirrori git bundle --all.

# 2 Punkt widzenia administratora

• Pliki treści
  • Przypadek specjalny „packfile”: git łączy i kompaktuje obiekty do plików packfile podczas czyszczenia pamięci (zobacz git gc)
• konfiguracja git
  • zobacz https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
  • docs: man git-config, man gitignore
  • .git / config
  • .git / description (dla hooków i narzędzi, np. hook post-accept-email, gitolite, GitWeb itp.)
  • .git / hooks /
  • .git / info / (plik wykluczający repozytorium itp.)
• Opcjonalnie: konfiguracja systemu operacyjnego (uprawnienia systemu plików itp.)

git jest narzędziem programistycznym i pozostawia to administratorowi. Kopię zapasową konfiguracji git i konfiguracji systemu operacyjnego należy traktować jako oddzielną od kopii zapasowej zawartości.

2. Techniki

• „Cold-Copy”
  • Zatrzymaj usługę, aby mieć wyłączny dostęp do jej plików. Przestój!
• „Hot-Copy”
  • Usługa zapewnia stały stan do celów kopii zapasowych. Bieżące zmiany nie wpływają na ten stan.

3. Inne tematy do przemyślenia

Większość z nich ma charakter ogólny do tworzenia kopii zapasowych.

• Czy jest wystarczająco dużo miejsca, aby pomieścić pełne kopie zapasowe? Ile pokoleń będzie przechowywanych?
• Czy potrzebne jest podejście przyrostowe? Ile pokoleń będzie przechowywanych i kiedy ponownie utworzyć pełną kopię zapasową?
• Jak sprawdzić, czy kopia zapasowa nie jest uszkodzona po utworzeniu lub w czasie?
• Czy system plików obsługuje twarde łącza?
• Umieścić kopię zapasową w jednym pliku archiwum lub użyć struktury katalogów?

4. Co git zapewnia do tworzenia kopii zapasowych zawartości

• git gc --auto

  • docs: man git-gc
  • Czyści i kompaktuje repozytorium.

• git bundle --all

  • docs: man git-bundle, man git-rev-list
  • Atomic = „Hot-Copy”
  • Pakiety są plikami zrzutu i mogą być bezpośrednio używane z git (weryfikacja, klonowanie itp.).
  • Obsługuje ekstrakcję przyrostową.
  • Weryfikowalne przez git bundle verify.

• git clone --mirror

  • docs: man git-clone, man git-fsck, Jaka jest różnica między git clone --mirror i git clone --bare
  • Atomic = „Hot-Copy”
  • Mirrory to prawdziwe repozytoria git.
  • Podstawową intencją tego polecenia jest zbudowanie pełnego aktywnego serwera lustrzanego, który okresowo pobiera aktualizacje z oryginalnego repozytorium.
  • Obsługuje twarde łącza do serwerów lustrzanych w tym samym systemie plików, aby uniknąć marnowania miejsca.
  • Weryfikowalne przez git fsck.
  • Mirrory mogą służyć jako podstawa do pełnego skryptu kopii zapasowej plików.

5. Kopia na zimno

Kopia zapasowa kopia zimno może zawsze zrobić pełną kopię zapasową pliku: zaprzeczyć wszystkie dostępy do repo git, czy tworzenie kopii zapasowych i ponownie umożliwić dostępy.

• Możliwe problemy
  • Może nie być łatwe - lub nawet możliwe - odmowa dostępu, np. Współdzielony dostęp przez system plików.
  • Nawet jeśli repozytorium znajduje się na komputerze tylko klienckim z jednym użytkownikiem, użytkownik nadal może popełnić coś podczas automatycznego wykonywania kopii zapasowej :(
  • Przestoje mogą być nie do zaakceptowania na serwerze, a tworzenie kopii zapasowych wielu dużych repozytoriów może zająć dużo czasu.
• Pomysły na łagodzenie skutków:
  • Generalnie zapobiegaj bezpośredniemu dostępowi do repozytoriów za pośrednictwem systemu plików, nawet jeśli klienci znajdują się na tym samym komputerze.
  • W przypadku dostępu SSH / HTTP użyj menedżerów autoryzacji git (np. Gitolite), aby dynamicznie zarządzać dostępem lub modyfikować pliki uwierzytelniające w sposób skryptowy.
  • Kopie zapasowe repozytorium jeden po drugim, aby skrócić przestoje dla każdego repozytorium. Odrzuć jedno repozytorium, wykonaj kopię zapasową i ponownie zezwól na dostęp, a następnie przejdź do następnego repozytorium.
  • Zaplanuj harmonogram konserwacji, aby uniknąć zdenerwowania programistów.
  • Kopia zapasowa tylko po zmianie repozytorium. Może bardzo trudne do zaimplementowania, np. Lista obiektów plus uwzględnienie plików packfile, sum kontrolnych konfiguracji i hooków itp.

6. Hot-Copy

Kopie zapasowe plików nie mogą być wykonywane z aktywnymi repozytoriami ze względu na ryzyko uszkodzenia danych w wyniku trwających zatwierdzeń. Gorąca kopia zapewnia stały stan aktywnego repozytorium na potrzeby tworzenia kopii zapasowych. Bieżące zatwierdzenia nie wpływają na tę kopię. Jak wspomniano powyżej, funkcje klonowania i paczki gita to obsługują, ale w przypadku kopii zapasowej „100% administratora” należy wykonać kilka czynności za pomocą dodatkowych poleceń.

Kopia zapasowa „100% administratora”

• Opcja 1: użyj git bundle --alldo tworzenia pełnych / przyrostowych plików zrzutu zawartości i kopiowania / tworzenia kopii zapasowych plików konfiguracyjnych oddzielnie.
• Opcja 2: git clone --mirrorosobno używaj , obsługuj i kopiuj konfigurację, a następnie wykonaj pełną kopię zapasową pliku lustrzanego.
  • Uwagi:
  • Lustro to nowe repozytorium, które jest zapełniane aktualnym szablonem git podczas tworzenia.
  • Wyczyść pliki konfiguracyjne i katalogi, a następnie skopiuj pliki konfiguracyjne z oryginalnego repozytorium źródłowego.
  • Skrypt kopii zapasowej może również zastosować konfigurację systemu operacyjnego, na przykład uprawnienia do plików na serwerze lustrzanym.
  • Użyj systemu plików obsługującego dowiązania twarde i utwórz kopię lustrzaną na tym samym systemie plików, co repozytorium źródłowe, aby zwiększyć szybkość i zmniejszyć zużycie miejsca podczas tworzenia kopii zapasowych.

7. Przywróć

• Sprawdź i zastosuj konfigurację git do maszyny docelowej i najnowszą filozofię „sposobu działania”.
• Sprawdź i zastosuj konfigurację systemu operacyjnego do maszyny docelowej i najnowszą filozofię „sposobu działania”.

cd /path/to/backupdir/
git clone /path/to/repo
cd /path/to/repo
git remote add backup /path/to/backupdir
git push --set-upstream backup master

tworzy to kopię zapasową i dokonuje konfiguracji, dzięki czemu możesz wykonać polecenie git push, aby zaktualizować kopię zapasową, co prawdopodobnie jest tym, co chcesz zrobić. Upewnij się tylko, że / path / to / backupdir i / path / to / repo to co najmniej różne dyski twarde, w przeciwnym razie nie ma to większego sensu.

Oto dwie opcje:

1. Możesz bezpośrednio pobrać plik tar z katalogu repozytorium git, ponieważ zawiera on całą zawartość repozytorium na serwerze. Istnieje niewielka możliwość, że ktoś może pracować nad repozytorium podczas tworzenia kopii zapasowej.

2. Następujące polecenie da ci czysty klon repozytorium (tak jak na serwerze), a następnie możesz bez problemu pobrać plik tar z lokalizacji, w której sklonowałeś.

   git clone --bare {your backup local repo} {new location where you want to clone}
   

Jeśli jest na Github, przejdź do bitbucket i użyj metody „import repository”, aby zaimportować repozytorium github jako repozytorium prywatne.

Jeśli jest w bitbuckecie, zrób na odwrót.

Jest to pełna kopia zapasowa, ale pozostaje w chmurze, co jest moją idealną metodą.

O ile wiem, możesz po prostu zrobić kopię katalogu, w którym znajduje się repozytorium, to wszystko!

cp -r project project-backup