Jak działa Git LFS: Overview of Git Large File Storage

Zespoły programistów na całym świecie używają Gita do zarządzania kodem źródłowym. A wiele z nich używa Git LFS – Git Large File Storage – do zarządzania i przechowywania dużych plików. Tutaj wyjaśniamy, co robi Git LFS i kiedy go używać.

Czy Git radzi sobie z dużymi plikami?

Git nie radzi sobie sam z dużymi plikami. Dlatego wiele zespołów Git dodaje Git LFS, aby poradzić sobie z dużymi plikami w Git.

Co to jest Git LFS (Git Large File Storage)?

Git LFS to rozszerzenie Git używane do zarządzania dużymi plikami i plikami binarnymi w oddzielnym repozytorium Git.

Większość dzisiejszych projektów ma zarówno kod, jak i zasoby binarne. A przechowywanie dużych plików binarnych w repozytoriach Git może być wąskim gardłem dla użytkowników Git.

Dlatego niektórzy użytkownicy Gita dodają Git Large File Storage (LFS).

Jak działa Git LFS?

Git LFS używa wskaźników zamiast rzeczywistych plików lub binarnych dużych obiektów (blobów).

Więc, zamiast pisać duże pliki/bloby do repozytorium Git, piszesz plik wskaźnika. A same pliki/bloby są zapisywane na oddzielnym serwerze. Możesz nawet używać wielu serwerów w Git LFS.

Rozpoczęcie pracy jest dość proste. Pobierasz rozszerzenie i konfigurujesz swoje typy plików.

Używanie Git LFS umożliwia wersjonowanie dużych plików (i zarządzanie blobami) przy jednoczesnym zwolnieniu miejsca w repozytoriach Git. A Git LFS jest często poprawką dla pchania dużych plików do GitHuba.

Problemy Git poza LFS

Git ma problemy poza Git LFS. A bezpieczeństwo jest jednym z nich. Natywnemu Gitowi brakuje bezpieczeństwa, a opcje dodatkowe do zabezpieczenia Gita nie są najlepsze. Dowiedz się, co powinieneś zrobić z bezpieczeństwem Gita w naszej białej księdze – How to Lock Down Git.

Lock Down Git

Should I Use Git LFS?

Powinieneś użyć Git LFS, jeśli masz duże pliki lub pliki binarne do przechowywania w repozytoriach Git.

To dlatego, że Git jest zdecentralizowany. Tak więc każdy programista ma pełną historię zmian na swoim komputerze. A zmiany w dużych plikach binarnych powodują, że repozytoria Git rosną o rozmiar tego pliku za każdym razem, gdy plik jest zmieniany (i ta zmiana jest popełniana). Oznacza to, że uzyskanie tych plików zajmie wieki. A jeśli to zrobisz, trudno będzie wersjonować i scalać pliki binarne.

Więc, za każdym razem, gdy pliki rosną, repozytorium Git rośnie. A kiedy użytkownicy Git muszą pobrać i sklonować repozytorium, stwarza to problemy.

Git LFS został stworzony, aby rozwiązać te problemy. Ale ma też swoje własne problemy…

Gdy Git Large File Storage nie działa

Git LFS działa. Ale zespoły ciągle mówią nam, że trudno jest nim zarządzać. Tak więc, mimo że sam Git jest darmowy, może podnieść koszty wydajności.

Instalacja Git LFS na każdym serwerze i stacji roboczej (i/lub repo) wymaga czasu. Obciąża też administratorów. Po zainstalowaniu, nie ma widoczności i nie ma nad nim kontroli. A jeśli niektórzy deweloperzy nie mają rozszerzenia Git LFS? To się rozpada.

Potrzebne są dodatkowe kroki, aby utrzymać Git Large File Storage z build runnerami, takimi jak Jenkins. To prowadzi do dodatkowego czasu – i dodatkowej złożoności.

Wszystko to może prowadzić do problemów z wydajnością.

Alternatywy dla Git LFS

Git LFS nie jest jedynym sposobem na zarządzanie dużymi plikami w Git. Istnieją alternatywy.

Obejmuje to inne poprawki open source lub stron trzecich, takie jak:

• git-annex
• git-bigfiles
• git-fat
• git-media
• git-bigstore
• git-sym

Ale, podobnie jak Git LFS, te opcje przechowywania dużych plików w Git mogą stwarzać problemy. Istnieje lepszy sposób na zarządzanie dużymi plikami i plikami binarnymi.

Najlepszy system kontroli wersji dla dużych plików binarnych: Helix Core

Dzisiejsze projekty są większe, z większą ilością plików i mieszanych aktywów niż kiedykolwiek wcześniej. Sam Git i Git LFS nie poradzą sobie z tym. Ale Helix Core może.

Helix Core – oprogramowanie do kontroli wersji firmy Perforce – jest najlepszą opcją do zarządzania dużymi plikami binarnymi. Dzieje się tak dlatego, że przechowywanie dużych plików jest jego natywną funkcją, a nie dodatkiem. I jest kuloodporne.

W Helix Core możesz przechowywać pliki binarne równolegle z kodem źródłowym. W rzeczywistości wszystkie największe pliki – pliki binarne, kod źródłowy, pliki graficzne, pliki wideo, obrazy, biblioteki i artefakty kompilacji – mogą żyć razem w jednym repozytorium. Bez spowalniania pracy dużych, rozproszonych zespołów.

Przekonaj się sam, dlaczego Helix Core jest najlepszym narzędziem do zarządzania dużymi plikami binarnymi.

Zarządzaj dużymi plikami w Helix Core

Przy okazji, Perforce ma też Git

Czy nadal masz zespoły, które muszą zarządzać dużymi plikami w Git? Możesz wprowadzić je do swojego potoku budowania dzięki narzędziom Perforce Git – Helix4Git i Helix TeamHub.

Helix4Git to serwer Git wewnątrz serwera Perforce. Helix TeamHub to rozwiązanie do hostingu kodu Git. Te narzędzia pozwalają zespołom Git na wykorzystanie szybkości i wydajności Helix Core – podczas pracy w Git.

Więc możesz użyć Helix4Git razem z Helix Core, aby wprowadzić swoje repozytorium Git do swojego potoku budowania. Helix4Git pozwala twoim programistom nadal korzystać z ich natywnych narzędzi Git. Ale otrzymują swoje pliki o wiele szybciej.

Zyskujesz:

• Szybszą wydajność kompilacji CI/CD.
• Wsparcie dla projektów z wieloma repo, repozytoriów artefaktów, a nawet rejestru kontenerów Docker.
• Możliwość stopniowego dodawania węzłów.
• Replikację i gwarantowaną aktualną zawartość bez opóźnień, zamiast kopiowania.

.