Zarządzanie dużymi plikami i przechowywanie ich w usłudze Git

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Git pomaga zachować mały ślad kodu źródłowego, ponieważ różnice między wersjami są łatwo zauważalne, a kod jest łatwo kompresowany. Duże pliki, które nie kompresują się dobrze i całkowicie zmieniają się między wersjami (takie jak pliki binarne), stanowią problemy podczas przechowywania w repozytoriach Git. Szybka wydajność usługi Git wynika z możliwości adresowania i przełączania się do wszystkich wersji pliku z magazynu lokalnego.

Jeśli masz duże, nieszyfnione pliki w repozytorium (na przykład pliki binarne), za każdym razem, gdy zatwierdzisz zmianę, zachowasz pełną kopię tych plików w repozytorium. Jeśli w repozytorium istnieje wiele wersji tych plików, znacznie zwiększają one czas na wyewidencjonowanie, rozgałęzienie, pobieranie i klonowanie kodu.

Jakiego rodzaju pliki należy przechowywać w usłudze Git?

Zatwierdź kod źródłowy, a nie zależności

Gdy twój zespół współpracuje z edytorami i narzędziami do tworzenia i aktualizowania plików, należy umieścić te pliki w usłudze Git, aby twój zespół mógł korzystać z zalet przepływu pracy usługi Git. Nie zatwierdzaj innych typów plików w repozytorium: na przykład plików DLL, plików biblioteki i innych zależności, które zespół nie tworzy, ale od których zależy kod. Dostarczaj te pliki za pomocą menedżera pakietów do swoich systemów.

Zarządzanie pakietami łączy zależności i instaluje pliki w systemie podczas wdrażania pakietu. Pakiety są wersjonowane w celu zapewnienia, że kod testowany w jednym środowisku działa tak samo w innym środowisku, o ile środowiska mają te same zainstalowane pakiety.

Nie zatwierdzaj danych wyjściowych

Nie zatwierdzaj plików binarnych, dzienników, wyników śledzenia ani danych diagnostycznych z kompilacji i testów. Są to dane wyjściowe z kodu, a nie z samego kodu źródłowego. Udostępnij dzienniki i informacje śledzenia z twoim zespołem za pomocą narzędzi śledzących elementy robocze lub poprzez wspólne udostępnianie plików zespołu.

Przechowywanie małych, rzadko aktualizowanych źródeł binarnych w usłudze Git

Pliki źródłowe binarne, które są rzadko aktualizowane, mają stosunkowo niewiele wersji zatwierdzonych. Nie zajmują dużo miejsca, jeśli rozmiar pliku jest mały. Obrazy dla sieci, ikony i inne mniejsze elementy graficzne mogą należeć do tej kategorii. Lepiej jest przechowywać te pliki w usłudze Git z resztą źródła, aby zespół mógł używać spójnego przepływu pracy.

Ważne

Nawet małe pliki binarne mogą powodować problemy, jeśli są często aktualizowane. Na przykład 100 zmian w pliku binarnym o rozmiarze 100 KB zużywa tyle samo miejsca co 10 zmian w pliku binarnym o rozmiarze 1 MB. Ze względu na częstotliwość aktualizacji mniejszy plik binarny spowolni wydajność rozgałęziania częściej niż duży plik binarny.

Nie wprowadzaj dużych, często aktualizowanych plików binarnych

Usługa Git zarządza jedną główną wersją pliku, a następnie przechowuje tylko różnice w stosunku do tej wersji w procesie znanym jako deltification. Deltification i kompresja plików umożliwiają usłudze Git przechowywanie całej historii kodu w lokalnym repozytorium. Duże pliki binarne zwykle zmieniają się całkowicie między wersjami i są często kompresowane. Te pliki są trudne do zarządzania, ponieważ różnice między wersjami są duże.

Git musi przechowywać całą zawartość każdej wersji pliku i ma trudności z oszczędzaniem miejsca przez deltafikację oraz kompresję. Przechowywanie pełnych wersji tych plików powoduje zwiększenie rozmiaru repozytorium wraz z upływem czasu. Zwiększony rozmiar repozytorium pogarsza wydajność operacji rozgałęziania, zwiększa czasy klonowania i rozszerza wymagania dotyczące przechowywania.

Strategie pracy z dużymi plikami źródłowymi binarnymi

• Nie zatwierdzaj skompresowanych archiwów danych. Lepiej jest usunąć dekompresję plików i zatwierdzić różnicowe źródła. Pozwól usłudze Git na kompresowanie danych w repozytorium.
• Unikaj zatwierdzania skompilowanego kodu i innych zależności binarnych. Zatwierdź źródło i skompiluj zależności lub użyj rozwiązania do zarządzania pakietami do wersjonowania i dostarcz te pliki do systemu.
• Przechowuj konfigurację i inne dane ustrukturyzowane w formatach zwykłego tekstu, które można porównać, takich jak JSON.

Co to jest Git LFS?

Jeśli masz pliki źródłowe z dużymi różnicami między wersjami i częstymi aktualizacjami, możesz użyć usługi Git Large File Storage (LFS) do zarządzania tymi typami plików. Git LFS to rozszerzenie usługi Git, które udostępnia dane opisujące duże pliki w zatwierdzeniu w repozytorium. Przechowuje zawartość pliku binarnego w oddzielnym magazynie zdalnym.

Kiedy klonujesz repozytorium i przełączasz gałęzie, Git LFS pobiera poprawną wersję z tego zdalnego magazynu. Lokalne narzędzia programistyczne działają z plikami w sposób przejrzysty, tak jakby były zatwierdzone bezpośrednio w twoim repozytorium.

Korzyści

Zaletą usługi Git LFS jest to, że twój zespół może korzystać ze znanego kompleksowego przepływu pracy usługi Git niezależnie od tego, jakie pliki tworzy twój zespół. Usługa LFS obsługuje duże pliki, aby zapobiec negatywnemu wpływowi na ogólne repozytorium. Ponadto od wersji 2.0 Git LFS obsługuje blokowanie plików, aby ułatwić zespołowi pracę nad dużymi zasobami, takimi jak filmy, dźwięki i mapy gier.

Usługa Git LFS jest jest w pełni obsługiwana i bezpłatna w usłudze Azure DevOps Services. Aby korzystać z LFS w programie Visual Studio, potrzebujesz programu Visual Studio 2015 Update 2 lub nowszego. Postępuj zgodnie z instrukcjami , aby zainstalować klienta, skonfigurować śledzenie LFS dla plików w lokalnym repozytorium, a następnie wypchnąć zmiany do usługi Azure Repos.

Ograniczenia

Usługa Git LFS ma pewne wady, które należy wziąć pod uwagę przed jego wdrożeniem:

• Każdy klient Git używany przez zespół musi zainstalować klienta Git LFS i zrozumieć jego konfigurację śledzenia.
• Jeśli klient usługi Git LFS nie jest zainstalowany i skonfigurowany poprawnie, nie zobaczysz plików binarnych zatwierdzonych za pośrednictwem usługi Git LFS podczas klonowania repozytorium. Usługa Git pobierze dane opisujące duży plik (czyli to, co usługa Git LFS zatwierdza w repozytorium), a nie plik binarny. Zakomitowanie dużych plików binarnych bez zainstalowanego klienta Git LFS spowoduje przesłanie pliku binarnego do repozytorium.
• Usługa Git nie może scalić zmian z dwóch różnych wersji pliku binarnego, nawet jeśli obie wersje mają wspólny element nadrzędny. Jeśli dwie osoby pracują nad tym samym plikiem w tym samym czasie, muszą ze sobą współpracować w celu uzgodnienia zmian, aby nie nadpisywać nawzajem swojej pracy. Rozszerzenie Git LFS oferuje funkcję blokowania plików, która ułatwia ten proces. Użytkownicy muszą dbać o to, aby zawsze przed rozpoczęciem pracy pobrać najnowszą kopię zasobu binarnego.
• Usługa Azure Repos obecnie nie obsługuje używania protokołu Secure Shell (SSH) w repozytoriach z plikami śledzonymi przez Git LFS.
• Jeśli użytkownik przeciąga plik binarny za pośrednictwem interfejsu internetowego do repozytorium skonfigurowanego dla usługi Git LFS, plik binarny jest zatwierdzany w repozytorium — a nie wskaźniki, które zostaną zatwierdzone za pośrednictwem klienta LFS usługi Git.
• Chociaż nie ma ścisłego ograniczenia rozmiaru pliku, dostępne wolne miejsce na serwerze i bieżące obciążenie może ograniczyć wydajność i funkcjonalność.
• Limit czasu dla jednego przekazywania plików wynosi jedną godzinę.

Format pliku

Plik zapisany do twojego repozytorium dla pliku śledzonego przez Git LFS zawiera kilka wierszy z parą klucz/wartość w każdym z nich.

version https://git-lfs.github.com/spec/v1
oid a747cfbbef63fc0a3f5ffca332ae486ee7bf77c1d1b9b2de02e261ef97d085fe
size 4923023

Uwaga

Adres URL usługi GitHub uwzględniony dla wartości wersji definiuje tylko typ pliku wskaźnika LFS. Nie jest to link do pliku binarnego.

Znane problemy

Jeśli używasz wersji LFS starszej niż 2.4.0 z usługą Azure DevOps Server, wymagany jest dodatkowy krok konfiguracji, aby uwierzytelnić się za pośrednictwem protokołu NTLM zamiast protokołu Kerberos. Ten krok nie jest już konieczny w wersji LFS 2.4.0 i zdecydowanie zalecamy uaktualnienie.