Udostępnij za pośrednictwem

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

  • Artykuł

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

Usługa Git pomaga zachować mały ślad kodu źródłowego, ponieważ różnice między wersjami są łatwo wybierane, a kod jest łatwo kompresowany. Duże pliki, które nie są dobrze kompresowane i które zmieniają się całkowicie między wersjami (takimi jak pliki binarne), występują problemy podczas ich 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?

Zatwierdzanie kodu źródłowego, 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 biblioteki DLL, plików biblioteki i innych zależności, od których zespół nie tworzy, ale zależy od kodu. Dostarczaj te pliki za pomocą zarządzania pakietami do 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, śledzenia danych wyjściowych ani danych diagnostycznych z kompilacji i testów. Są to dane wyjściowe z kodu, a nie z samego kodu źródłowego. Udostępnianie dzienników i informacji śledzenia zespołowi za pomocą narzędzi do śledzenia elementów roboczych lub udostępniania plików zespołu.

Przechowywanie małych, często 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 Web, ikon i innych mniejszych zasobów sztuki 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 używa aż 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 zatwierdzaj dużych, często aktualizowanych zasobów binarnych

Usługa Git zarządza jedną główną wersją pliku, a następnie przechowuje tylko różnice z 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.

Usługa Git musi przechowywać całą zawartość każdego pliku i ma trudności z oszczędzaniem miejsca przez deltification i kompresję. Przechowywanie pełnych wersji tych plików powoduje zwiększenie rozmiaru repozytorium wraz z upływem czasu. Zwiększony rozmiar repozytorium zmniejsza wydajność rozgałęziania, zwiększa czas klonowania i rozszerza wymagania dotyczące magazynu.

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 wersji i podaj te pliki w systemie.
  • Przechowuj konfigurację i inne dane ustrukturyzowane w formatach zwykłego tekstu, 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.

Gdy klonujesz i przełączasz gałęzie w repozytorium, rozszerzenie Git LFS pobiera poprawną wersję z tego magazynu zdalnego. Lokalne narzędzia programistyczne działają w sposób niewidoczny dla plików, tak jakby zostały one zatwierdzone bezpośrednio w repozytorium.

Świadczenia

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 rozszerzenie Git LFS obsługuje blokowanie plików, aby ułatwić zespołowi pracę nad dużymi elementami zawartości, takimi jak filmy, dźwięki i mapy gier.

Usługa Git LFS jest w pełni obsługiwana i bezpłatna w usługach 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 Usługi Git używany przez zespół musi zainstalować klienta usługi Git LFS i zrozumieć jego konfigurację śledzenia.
  • Jeśli klient Git LFS nie zostanie zainstalowany i skonfigurowany poprawnie, nie będziesz widzieć plików binarnych zatwierdzonych za pośrednictwem rozszerzenia 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. Zatwierdzenie dużych plików binarnych bez zainstalowanego klienta Git LFS spowoduje wypchnięcie 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ą zachować ostrożność i zawsze przed rozpoczęciem pracy ściągnąć najnowszą kopię binarnego elementu zawartości.
  • Usługa Azure Repos obecnie nie obsługuje używania protokołu Secure Shell (SSH) w repozytoriach z śledzonym plikami 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ę.

File format

Plik zapisany w repozytorium dla śledzonego pliku Git LFS zawiera kilka wierszy z parą klucz/wartość w każdym wierszu:

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 do uwierzytelniania 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.