Zarządzanie dużymi plikami binarnymi za pomocą Git

Szukam opinii na temat obsługi dużych plików binarnych, od których zależy mój kod źródłowy (aplikacja internetowa). Obecnie omawiamy kilka alternatyw:

1. Skopiuj pliki binarne ręcznie.
   • Pro: Nie jestem pewien.
   • Przeciw: jestem zdecydowanie temu przeciwny, ponieważ zwiększa to prawdopodobieństwo błędów podczas konfigurowania nowej witryny / migrowania starej. Stwarza kolejną przeszkodę do pokonania.
2. Zarządzaj nimi wszystkimi za pomocą Git .
   • Pro: usuwa możliwość „zapomnienia” o skopiowaniu ważnego pliku
   • Contra: Nadęża repozytorium i zmniejsza elastyczność zarządzania bazą kodu, a kasy, klony itp. Zajmą sporo czasu.
3. Oddzielne repozytoria.
   • Pro: Sprawdzanie / klonowanie kodu źródłowego jest szybkie jak zawsze, a obrazy są odpowiednio archiwizowane w ich własnym repozytorium.
   • Contra: Usuwa prostotę posiadania jedynego repozytorium Git w projekcie. Z pewnością wprowadza kilka innych rzeczy, o których nie myślałem.

Jakie są twoje doświadczenia / przemyślenia na ten temat?

Ponadto: Czy ktoś ma doświadczenie z wieloma repozytoriami Git i zarządzaniem nimi w jednym projekcie?

Pliki są obrazami dla programu, który generuje pliki PDF z zawartymi w nich plikami. Pliki nie zmieniają się bardzo często (jak w latach), ale są bardzo istotne dla programu. Program nie będzie działać bez plików.

Jeśli program nie będzie działał bez plików, wydaje się, że podzielenie ich na osobne repozytorium jest złym pomysłem. Mamy duże pakiety testowe, które dzielimy na osobne repozytorium, ale są to naprawdę pliki „pomocnicze”.

Jednak możesz być w stanie zarządzać plikami w osobnym repozytorium, a następnie użyć git-submoduledo wciągnięcia ich do projektu w rozsądny sposób. Tak więc nadal będziesz mieć pełną historię wszystkich swoich źródeł, ale, jak rozumiem, będziesz mieć tylko jedną odpowiednią wersję podmodułu swoich zdjęć. Narzędzie git-submodulepowinno pomóc w utrzymaniu poprawnej wersji kodu zgodnej z poprawną wersją obrazów.

Oto dobre wprowadzenie do submodułów z Git Book.

Niedawno odkryłem załącznik git, który wydaje mi się niesamowity. Został zaprojektowany do wydajnego zarządzania dużymi plikami. Używam go do moich kolekcji zdjęć / muzyki (itp.). Rozwój git-Annex jest bardzo aktywny. Zawartość plików można usunąć z repozytorium Git, tylko hierarchia drzewa jest śledzona przez Git (poprzez dowiązania symboliczne). Jednak, aby uzyskać zawartość pliku, po pociągnięciu / pchnięciu konieczny jest drugi krok, np .:

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

Dostępnych jest wiele poleceń, a na stronie znajduje się świetna dokumentacja. Pakiet jest dostępny na Debianie .

Kolejnym rozwiązaniem, od kwietnia 2015 r., Jest Git Large File Storage (LFS) (firmy GitHub).

Używa git-lfs (patrz git-lfs.github.com ) i przetestowano na serwerze, który go obsługuje: lfs-test-server :
metadane można przechowywać tylko w repozytorium git, a duży plik w innym miejscu.

Spójrz na git bup, który jest rozszerzeniem Git do inteligentnego przechowywania dużych plików binarnych w repozytorium Git.

Chciałbyś mieć go jako submoduł, ale nie będziesz musiał się martwić, że repozytorium będzie trudne w obsłudze. Jednym z przykładowych przypadków użycia jest przechowywanie obrazów VM w Git.

Właściwie nie widziałem lepszych współczynników kompresji, ale moje repozytoria nie mają naprawdę dużych plików binarnych.

Twój przebieg może się różnić.

Możesz także użyć git-fat . Podoba mi się, że to zależy tylko od zapasów Python i rsync. Obsługuje również zwykły obieg pracy Git, za pomocą następujących poleceń wyjaśniających:

git fat init
git fat push
git fat pull

Ponadto musisz zarejestrować plik .gitfat w repozytorium i zmodyfikować atrybuty .gitattat, aby określić rozszerzenia plików, którymi chcesz git fatzarządzać.

Dodajesz plik binarny przy użyciu normalnego git add, który z kolei wywołuje się git fatna podstawie reguł gitattributes.

Wreszcie ma tę zaletę, że miejsce, w którym faktycznie przechowywane są pliki binarne, może być współużytkowane przez repozytoria i użytkowników i obsługuje wszystko, co rsyncrobi.

AKTUALIZACJA: Nie używaj git-fat, jeśli używasz mostu Git-SVN. Spowoduje to usunięcie plików binarnych z repozytorium Subversion. Jeśli jednak używasz czystego repozytorium Git, działa ono pięknie.

Użyłbym submodułów (jako Pat Notz) lub dwóch różnych repozytoriów. Jeśli zbyt często modyfikujesz swoje pliki binarne, to spróbuję zminimalizować wpływ ogromnego repozytorium czyszczącego historię:

Kilka miesięcy temu miałem bardzo podobny problem: ~ 21 GB plików MP3, niesklasyfikowane (złe nazwy, złe id3, nie wiem, czy podoba mi się ten plik MP3, czy nie ...) i powielone na trzech komputerach.

Użyłem zewnętrznego dysku twardego z głównym repozytorium Git i sklonowałem go na każdym komputerze. Następnie zacząłem klasyfikować je w zwykły sposób (pchanie, ciągnięcie, łączenie ... usuwanie i zmiana nazwy wiele razy).

Na koniec miałem tylko ~ 6 GB plików MP3 i ~ 83 GB w katalogu .git. Użyłem git-write-treei git-commit-treedo utworzenia nowego zatwierdzenia, bez przodków zatwierdzeń, i założyłem nową gałąź wskazującą na to zatwierdzenie. „Git log” dla tej gałęzi pokazał tylko jedno zatwierdzenie.

Następnie usunąłem starą gałąź, zachowałem tylko nową gałąź, usunąłem dzienniki referencji i uruchomiłem „git prune”: potem moje foldery .git ważyły ​​tylko ~ 6 GB ...

Możesz od czasu do czasu „wyczyścić” ogromne repozytorium w ten sam sposób: Twój „git clone” będzie szybszy.

Rozwiązanie, które chciałbym zaproponować, opiera się na sierocych gałęziach i lekkim nadużyciu mechanizmu tagów, odtąd zwanym * Orphan Tags Binary Storage (OTABS)

TL; DR 12-01-2017 Jeśli możesz korzystać z LFS github lub innej strony trzeciej, to zdecydowanie powinieneś. Jeśli nie możesz, czytaj dalej. Ostrzegamy, że to rozwiązanie jest hackem i powinno być traktowane jako takie.

Pożądane właściwości OTABS

• jest to rozwiązanie typu „ tylko git i git” - wykonuje zadanie bez żadnego oprogramowania zewnętrznego (takiego jak git-annex) lub infrastruktury innej firmy (jak LFS github).
• skutecznie przechowuje pliki binarne , tzn. nie przesadza z historią Twojego repozytorium.
• git pulli git fetch, w tym git fetch --allnadal są wydajne w zakresie przepustowości , tj. domyślnie nie wszystkie duże pliki binarne są pobierane ze zdalnego.
• działa w systemie Windows .
• przechowuje wszystko w jednym repozytorium git .
• pozwala na usunięcie przestarzałych plików binarnych (w przeciwieństwie do bup).

Niepożądane właściwości OTABS

• czyni to git clonepotencjalnie nieefektywnym (ale niekoniecznie, w zależności od użytkowania) Jeśli wdrożyć to rozwiązanie może trzeba doradzić swoich kolegów do użycia git clone -b master --single-branch <url>zamiast git clone. Wynika to z tego, że git klonuje domyślnie dosłownie klonuje całe repozytorium, w tym rzeczy, na które normalnie nie chciałbyś tracić przepustowości, takie jak nieprecyzyjne zatwierdzenia. Zaczerpnięte z SO 4811434 .
• powoduje to, że git fetch <remote> --tagsprzepustowość jest nieefektywna, ale niekoniecznie nieefektywna. Zawsze możesz poradzić kolegom, aby go nie używali.
• będziesz musiał okresowo korzystać ze git gcsztuczki, aby wyczyścić repozytorium z plików, których już nie chcesz.
• nie jest tak wydajny jak bup lub git-bigfiles . Ale jest odpowiednio bardziej odpowiedni do tego, co próbujesz zrobić, i bardziej dostępny z półki. Prawdopodobnie będziesz mieć problemy z setkami tysięcy małych plików lub z plikami w zakresie gigabajtów, ale czytaj dalej w celu obejścia tego problemu.

Dodawanie plików binarnych

Przed rozpoczęciem upewnij się, że dokonałeś wszystkich zmian, twoje drzewo robocze jest aktualne, a Twój indeks nie zawiera żadnych niezatwierdzonych zmian. Dobrym pomysłem może być zepchnięcie wszystkich lokalnych oddziałów do zdalnego (github itp.) Na wypadek katastrofy.

1. Utwórz nową gałąź osieroconą. git checkout --orphan binaryStuffda rade. Powoduje to utworzenie gałęzi całkowicie odłączonej od jakiejkolwiek innej gałęzi, a pierwsze zatwierdzenie dokonane w tej gałęzi nie będzie miało elementu nadrzędnego, co spowoduje, że będzie to zatwierdzenie główne.
2. Wyczyść swój indeks za pomocą git rm --cached * .gitignore.
3. Weź głęboki oddech i usuń całe działające drzewo za pomocą rm -fr * .gitignore. .gitKatalog wewnętrzny pozostanie nietknięty, ponieważ *symbol wieloznaczny nie pasuje do niego.
4. Skopiuj do VeryBigBinary.exe lub VeryHeavyDirectory /.
5. Dodaj i zatwierdz go.
6. Teraz staje się to trudne - jeśli wepchniesz go do pilota jako gałąź, wszyscy twoi programiści pobiorą go następnym razem, gdy wywołają git fetchzatykanie połączenia. Można tego uniknąć, naciskając tag zamiast gałęzi. Może to nadal wpływać na przepustowość i pamięć systemu współpracownika, jeśli mają one zwyczaj pisania git fetch <remote> --tags, ale czytają w celu obejścia tego problemu. Śmiało igit tag 1.0.0bin
7. Wciśnij sierotę git push <remote> 1.0.0bin.
8. Abyś nigdy nie przypadkowo wypchnął gałęzi binarnej, możesz ją usunąć git branch -D binaryStuff. Twoje zatwierdzenie nie zostanie oznaczone do odśmiecania, ponieważ wskazany na nim sierocy tag 1.0.0binwystarczy, aby utrzymać go przy życiu.

Sprawdzanie pliku binarnego

1. Jak mogę (lub moi koledzy) pobrać VeryBigBinary.exe do bieżącego działającego drzewa? Jeśli Twoja obecna działająca gałąź to na przykład master, możesz po prostu git checkout 1.0.0bin -- VeryBigBinary.exe.
2. To się nie powiedzie, jeśli nie 1.0.0binpobrałeś sierocego znacznika , w takim przypadku musisz to zrobić git fetch <remote> 1.0.0binwcześniej.
3. Możesz dodać to VeryBigBinary.exedo swojego mistrza .gitignore, aby nikt z twojego zespołu nie przypadkiem zanieczyścił główną historię projektu plikiem binarnym.

Całkowicie usuwając plik binarny

Jeśli zdecydujesz się całkowicie usunąć VeryBigBinary.exe z lokalnego repozytorium, zdalnego repozytorium i repozytoriów współpracownika, możesz po prostu:

1. Usuń znacznik osierocony na pilocie git push <remote> :refs/tags/1.0.0bin
2. Usuń lokalnie znacznik osierocony (usuwa wszystkie inne niepowiązane znaczniki) git tag -l | xargs git tag -d && git fetch --tags. Zaczerpnięte z SO 1841341 z niewielkimi modyfikacjami.
3. Użyj sztuczki git gc, aby usunąć lokalnie teraz brak odwołania do zatwierdzenia. git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@". Spowoduje to również usunięcie wszystkich innych niepowiązanych zatwierdzeń. Zaczerpnięte z SO 1904860
4. Jeśli to możliwe, powtórz lewę git gc na pilocie. Jest to możliwe, jeśli samo hostujesz swoje repozytorium i może nie być możliwe u niektórych dostawców git, takich jak github lub w niektórych środowiskach korporacyjnych. Jeśli prowadzisz hosting u dostawcy, który nie daje ci dostępu ssh do pilota, po prostu pozwól mu być. Możliwe jest, że infrastruktura twojego dostawcy wyczyści twoje niereferencyjne zatwierdzenie w swoim słodkim czasie. Jeśli pracujesz w środowisku korporacyjnym, możesz doradzić działowi IT, aby raz na tydzień uruchamiał śmieci cron, zbierając pilota. To, czy zrobią to, czy nie, nie będzie miało żadnego wpływu na Twój zespół pod względem przepustowości i pamięci, o ile doradzasz kolegom, aby zawsze git clone -b master --single-branch <url>zamiast tego git clone.
5. Wszyscy twoi koledzy, którzy chcą pozbyć się przestarzałych tagów osieroconych, muszą zastosować tylko kroki 2-3.
6. Następnie możesz powtórzyć kroki 1-8 dodawania plików binarnych, aby utworzyć nowy znacznik osierocony 2.0.0bin. Jeśli martwisz się, że koledzy piszą git fetch <remote> --tags, możesz to nazwać ponownie 1.0.0bin. Zapewni to, że następnym razem, gdy pobiorą wszystkie tagi, stare nie 1.0.0binbędą się odwoływać i zostaną oznaczone do późniejszego wyrzucania elementów bezużytecznych (przy użyciu kroku 3). Kiedy próbujesz zastąpić tag na pilocie, musisz użyć -ftego w następujący sposób:git push -f <remote> <tagname>

Posłowie

• OTABS nie dotyka twojego głównego ani żadnego innego kodu źródłowego / gałęzi programistycznych. Hasła zatwierdzania, cała historia i niewielki rozmiar tych gałęzi pozostają nienaruszone. Jeśli już rozdęłeś swoją historię kodu źródłowego plikami binarnymi, musisz ją wyczyścić jako osobny kawałek pracy. Ten skrypt może być przydatny.

• Potwierdzony do pracy w systemie Windows z git-bash.

• Dobrym pomysłem jest zastosowanie zestawu standardowych trików, aby zwiększyć efektywność przechowywania plików binarnych. Częste uruchamianie git gc(bez żadnych dodatkowych argumentów) powoduje, że git optymalizuje podstawowe przechowywanie plików za pomocą binarnych delt. Jeśli jednak twoje pliki raczej nie będą podobne do zatwierdzonych, możesz całkowicie wyłączyć binarne delty. Dodatkowo, ponieważ nie ma sensu kompresować już skompresowanych lub zaszyfrowanych plików, takich jak .zip, .jpg lub .crypt, git pozwala wyłączyć kompresję podstawowej pamięci. Niestety jest to ustawienie „wszystko albo nic”, które wpływa również na kod źródłowy.

• Możesz napisać skrypt do części OTABS, aby umożliwić szybsze użycie. W szczególności wykonywanie skryptów w krokach 2–3 od całkowitegoupdate usunięcia plików binarnych do haka git może dać przekonującą, ale być może niebezpieczną semantykę pobierania git („pobierz i usuń wszystko, co jest nieaktualne”).

• Możesz pominąć krok 4 Całkowicie usuwając pliki binarne, aby zachować pełną historię wszystkich zmian binarnych na pilocie, kosztem wzdęcia centralnego repozytorium. Lokalne repozytoria z czasem pozostaną szczupłe.

• W świecie Java można połączyć to rozwiązanie z, maven --offlineaby stworzyć odtwarzalną kompilację offline przechowywaną całkowicie w twojej kontroli wersji (łatwiej jest z maven niż z gradem). W świecie Golang możliwe jest wykorzystanie tego rozwiązania do zarządzania GOPATH zamiast go get. W świecie python można to połączyć z virtualenv, aby stworzyć niezależne środowisko programistyczne bez polegania na serwerach PyPi dla każdej kompilacji od zera.

• Jeśli pliki binarne zmieniają się bardzo często, jak budowania artefakty, to może być dobry pomysł, aby skrypt roztworze, który przechowuje 5 najnowsze wersje artefaktów w znacznikach sierocych monday_bin, tuesday_bin, ..., friday_bin, a także znacznik sierota dla każdego wydania 1.7.8bin 2.0.0binitp. Możesz codziennie obracać weekday_bini usuwać stare pliki binarne. W ten sposób otrzymujesz to, co najlepsze z dwóch światów: przechowujesz całą historię kodu źródłowego, ale tylko odpowiednią historię zależności binarnych. Bardzo łatwo jest również pobrać pliki binarne dla danego znacznika bez pobierania całego kodu źródłowego z całą jego historią: git init && git remote add <name> <url> && git fetch <name> <tag>należy to zrobić za Ciebie.

Moim zdaniem, jeśli prawdopodobnie często modyfikujesz te duże pliki, lub jeśli zamierzasz zrobić dużo git clonelub git checkout, powinieneś poważnie rozważyć użycie innego repozytorium Git (lub może innego sposobu dostępu do tych plików).

Ale jeśli pracujesz tak jak my, a twoje pliki binarne nie są często modyfikowane, pierwszy klon / kasa będzie długi, ale potem powinien być tak szybki, jak chcesz (biorąc pod uwagę, że użytkownicy nadal używają pierwszego sklonowanego repozytorium, miał).

SVN wydaje się radzić sobie z deltami binarnymi wydajniej niż Git.

Musiałem zdecydować się na system kontroli wersji dokumentacji (pliki JPEG, pliki PDF i pliki .odt). Właśnie przetestowałem dodanie pliku JPEG i czterokrotne obrócenie go o 90 stopni (aby sprawdzić skuteczność delt binarnych). Repozytorium Gita wzrosło o 400%. Repozytorium SVN wzrosło tylko o 11%.

Wygląda więc na to, że SVN jest znacznie wydajniejszy w przypadku plików binarnych.

Więc wybrałem Git dla kodu źródłowego i SVN dla plików binarnych, takich jak dokumentacja.

git clone --filter z Git 2.19 + płytkie klony

Ta nowa opcja może ostatecznie stać się ostatecznym rozwiązaniem problemu z plikiem binarnym, jeśli deweloperzy Git i GitHub uczynią go wystarczająco przyjaznym dla użytkownika (czego zapewne wciąż nie osiągnęli dla podmodułów ).

Umożliwia pobieranie plików i katalogów tylko dla serwera i został wprowadzony wraz ze zdalnym rozszerzeniem protokołu.

Dzięki temu możemy najpierw wykonać płytki klon, a następnie zautomatyzować, które obiekty BLOB mają być pobierane za pomocą systemu kompilacji dla każdego typu kompilacji.

Jest nawet już --filter=blob:limit<size> która pozwala ograniczyć maksymalny rozmiar obiektu blob do pobrania.

Podałem minimalny szczegółowy przykład tego, jak wygląda ta funkcja: Jak sklonować podkatalog tylko repozytorium Git?

Szukam opinii na temat obsługi dużych plików binarnych, od których zależy mój kod źródłowy (aplikacja internetowa). Jakie są twoje doświadczenia / przemyślenia na ten temat?

Osobiście natknąłem się na awarie synchronizacji z Git na niektórych moich hostach w chmurze, gdy moje dane binarne aplikacji internetowych spadły powyżej 3 GB . Zastanawiałem się wtedy nad BFT Repo Cleaner , ale czułem się jak hack. Od tego czasu zacząłem trzymać pliki poza zasięgiem Git, zamiast tego wykorzystując specjalnie zaprojektowane narzędzia, takie jak Amazon S3, do zarządzania plikami, wersjonowania i tworzenia kopii zapasowych.

Czy ktoś ma doświadczenie z wieloma repozytoriami Git i zarządzaniem nimi w jednym projekcie?

Tak. Motywami Hugo zarządza się przede wszystkim w ten sposób. To trochę kudłate, ale wykonuje pracę.

Moją propozycją jest wybranie odpowiedniego narzędzia do pracy . Jeśli jest to dla firmy i zarządzasz linią w GitHub, zapłać pieniądze i skorzystaj z Git-LFS. W przeciwnym razie możesz odkryć bardziej kreatywne opcje, takie jak zdecentralizowane, szyfrowane przechowywanie plików za pomocą blockchain .

Dodatkowe opcje do rozważenia to Minio i s3cmd .

Spójrz na camlistore . Nie jest tak naprawdę oparty na Git, ale uważam, że jest bardziej odpowiedni do tego, co musisz zrobić.