Git lfs

Git stał się de facto systemem kontroli wersji dla programistów na całym świecie. Ten system kontroli wersji rozproszonej w otwartym source jest szybszy niż jego konkurenci. Jest łatwy w użyciu do kodu rozgałęzienia i scalania. Ma jednak problem z wydajnością z dużymi plikami binarnymi. Git Large File Storage (LFS) został opracowany w celu rozwiązania tego problemu.

Duży problem z plikiem w git

Tradycyjnie niektóre firmy i instytucje trzymały się z dala od git z powodu nieefektywności w dużej obsłudze plików binarnych. Twórcy gier wideo i firmy medialne mają do czynienia ze złożonymi teksturami, filmami pełnometrażowymi i wysokiej jakości plikami audio. Instytuty badawcze muszą śledzić duże zestawy danych, które mogą być gigabajty lub terabajty. Git ma trudności z utrzymaniem tych dużych plików.

Aby zrozumieć problem, musimy przyjrzeć się, w jaki sposób Git śledzi pliki. Ilekroć jest zatwierdzenie, Git tworzy węzeł obiektowy z wskaźnikiem dla swojego rodzica lub wielu rodziców. Model danych GIT jest znany jako ukierunkowany wykres acykliczny (DAG). Model DAG zapewnia, że ​​relacja rodzic-dziecko nigdy nie może utworzyć żadnych cykli.

Możemy sprawdzić wewnętrzne działanie modelu DAG. Oto przykład trzech zobowiązań w repozytorium:

$ git log -linia
2beb263 Commit C: Dodano obraz1.JPEG
866178e commit b: Dodaj b.tekst
D48DD8B COMPIM A: Dodaj.tekst

W Commit A i B dodaliśmy plik tekstowy a.txt i b.tekst. Następnie w Commit C dodaliśmy plik obrazu o nazwie Image1.JPEG. Możemy wizualizować DAG jako następujące:

Zatwierdzić c commit b commit a
2beb263 -> 866178e -> D48dd8b

Jeśli sprawdzimy ostatnie zatwierdzenie za pomocą następującego polecenia:

$ git kota -plik -p 2beb263
Tree 7cc17Ba5B041FB227B9AB5534D81BD836183A4E3
rodzic 866178e37df64d9f19fa77c00d5ba9d3d4fc68f5
Autor Zak H 1513259427 -0800
Committer Zak H 1513259427 -0800
Commit C: Dodano obraz 1.JPEG

Widzimy, że Commit C (2beb263) ma zatwierdzenie B (866178e) jako rodzic. Teraz, jeśli sprawdzimy obiekt drzewa commit c (7cc17ba), możemy zobaczyć plamy (duże obiekty binarne):

$ git cat -plik -p 7cc17ba
100644 Blob E69DE29BB2D1D6434B8B29AE775AD8C2E48C5391 A.tekst
100644 Blob E69DE29BB2D1D6434B8B29AE775AD8C2E48C5391 B.tekst
100644 Blob A44A66F9E06A8FAF324D3FF3E11C9FA69666666666666666666 Image1.JPEG

Możemy sprawdzić rozmiar plamy obrazu:

$ git cat -file -S a44a66f9e
871680

Git śledzi zmiany w tej strukturze drzewa. Zróbmy modyfikację obrazu1.JPEG i sprawdź historię:

$ git log -linia
2E257DB Commit D: Zmodyfikowany obraz1.JPEG
2beb263 Commit C: Dodano obraz1.JPEG
866178e commit b: Dodaj b.tekst
D48DD8B COMPIM A: Dodaj.tekst

Jeśli sprawdzimy obiekt zatwierdzenia (2E257DB):

$ git cat -plik -p 2e257db
Drzewo 2405FAD67610ACF0F57B87AF36F535C1F4F9ED0D
Parent 2BEB263523725E1E8F9D96083140A4A5CD30B651
Autor Zak H 1513272250 -0800
Committer Zak H 1513272250 -0800
Commit D: Zmodyfikowany obraz 1.JPEG

I drzewo (2405fad) w nim:

$ git kota -plik -p 2405fad
100644 Blob E69DE29BB2D1D6434B8B29AE775AD8C2E48C5391 A.tekst
100644 Blob E69DE29BB2D1D6434B8B29AE775AD8C2E48C5391 B.tekst
100644 Blob CB4A0B67280A92412A81C60DF36A15150E713095 Image1.JPEG

Zauważ, że Hash SHA-1 dla Image1.JPEG się zmienił. Oznacza to, że stworzył nowy Blob dla Image1.JPEG. Możemy sprawdzić rozmiar nowego kropki:

$ git plik kotów -s CB4A0B6
1063696

Oto sposób na wizualizację powyższej struktury DAG:

Commit d commit c commit b
|. |. |. |
2E257DB -> 2BEB263 -> 866178E -> D48DD8B
|. |. |. |
Tree4 Tree3 Tree2 Tree1
|. |. |. |
Blob Blobs Blobs Blobs
[/cce_c]
Każdy obiekt zatwierdzenia utrzymuje własne drzewo. Blob są utrzymywane w tym drzewie. Git optymalizuje przestrzeń, upewniając się, że przechowuje tylko różnice i wykorzystuje kompresję do przechowywania. Ale w przypadku zmian plików binarnych GIT musi przechowywać całe pliki na obiektach, ponieważ trudno jest określić różnice. Ponadto pliki obrazu, wideo i audio są już kompresowane. W rezultacie dla każdej instancji zmodyfikowanego pliku binarnego drzewo kończy się dużą kroplą.
Pomyślmy o przykładu, w którym wprowadzamy wiele zmian w pliku obrazu 100 MB.
[CC Width = "100%" Height = "100%" ENDAPED = "True" Theme = "Blackboard" nowrap = "0"]
Commit c -> commit b -> commit a
|. |. |
Tree3 Tree2 Tree1
|. |. |
Blob3 Blob2 Blob1
300 MB 200 MB 100 MB
[/cce_c]
Za każdym razem, gdy zmieniamy plik, Git musi utworzyć kropelkę 100 MB. Tak więc dopiero po 3 zatwierdzenia repozytorium GIT wynosi 300 MB. Widać, że rozmiar repozytorium git może szybko wysadzić. Ponieważ GIT jest kontrolą wersji rozproszonej, zamierzasz pobrać całe repozytorium na lokalną instancję i dużo pracować z oddziałami. Tak więc duże plamy stają się wąskim gardłem.
Git LFS rozwiązuje problem, zastępując plamy lekkim plikami wskaźnikowymi (PF) i tworząc mechanizm przechowywania plamy gdzie indziej.
[CC Width = "100%" Height = "100%" ENDAPED = "True" Theme = "Blackboard" nowrap = "0"]
Commit c -> commit b -> commit a
|. |. |
Tree3 Tree2 Tree1
|. |. |
PF3 PF2 PF1
[/cce_c]
Lokalnie Git przechowuje plamy w pamięci podręcznej Git LFS, a zdalnie przechowuje je w sklepie Git LFS na Github lub Bitbucket.
[CC Width = "100%" Height = "100%" ENDAPED = "True" Theme = "Blackboard" nowrap = "0"]
PF1 -> BLOB1
PF2 -> BLOB2
PF3 -> BLOB3
[/cce_bash]
Teraz, gdy masz do czynienia z repozytorium GIT, do operacji rutynowych będą używane lekkie pliki PF. Blob zostaną odzyskane tylko w razie potrzeby. Na przykład, jeśli sprawdzisz Commit C, git LFS będzie wyszukał wskaźnik pf3 i pobierze Blob3. Więc działające repozytorium będzie szczuplejsze, a wydajność będzie lepsza. Nie musisz się martwić o pliki wskaźnika. Git LFS zarządzi nimi za kulisami.

Instalowanie i uruchamianie git lfs

Wcześniejsza próba rozwiązania problemu z dużym plikiem GIT. Ale Git LFS się udało, ponieważ jest łatwy w użyciu. Musisz tylko zainstalować LF i poinformować, które pliki śledzić.
Możesz zainstalować GIT LFS za pomocą następujących poleceń:
[CC Width = "100%" Height = "100%" ENDAPED = "True" Theme = "Blackboard" nowrap = "0"]
$ sudo apt-get instaluj oprogramowanie-properties-common
$ curl -s https: // packagecloud.IO/instalowanie/repozytoria/github/git-lfs/skrypt.Deb.sh | Sudo Bash
$ sudo apt-get instaluj git-lfs
$ git lfs instaluj

Po zainstalowaniu GIT LFS możesz śledzić żądane pliki:

$ git lfs tor ”*.JPEG "
Śledzenie ”*.JPEG "

Wyjście pokazuje, że GIT LFS śledzi pliki JPEG. Kiedy zaczniesz śledzić z LFS, znajdziesz .plik gitattributes, który będzie miał wpis pokazujący śledzone pliki. .plik Gitattributes Użyj tej samej notacji co .plik Gitignore. Oto jak treść .Gitattributes wygląda:

$ cat .Gitattributes
*.JPEG Filter = LFS diff = LFS Merge = LFS -Text

Możesz także znaleźć, które pliki są śledzone za pomocą następującego polecenia:

$ git lfs tor
Wzorce śledzenia
*.JPEG (.Gitattributes)

Jeśli chcesz przestać śledzić plik, możesz użyć następującego polecenia:

$ git lfs untrack "*.JPEG "
Untracking "*.JPEG "

W przypadku operacji ogólnych git nie musisz się martwić o LFS. Automatycznie zajmie się to wszystkimi zadaniami backendowymi. Po skonfigurowaniu GIT LFS możesz pracować nad repozytorium jak każdy inny projekt.

---

Dalsze badanie

Aby uzyskać bardziej zaawansowane tematy, spójrz na następujące zasoby:

• Poruszanie repozytorium GIT LFS między hostami
• Usuwanie lokalnych plików GIT LFS
• Usuwanie zdalnych plików GIT LFS z serwera
• Witryna Git LFS
• Dokumentacja Git LFS

Bibliografia:

• git-lfs.github.com: github repo
• github.com/git-lfs/git-lfs/drzewo/master/dokumenty: dokumentacja github dla git lfs
• Atlassian.com/git/tutorials/git-lfs: Atlassian Tutorials
• youtube.com: co to jest git lfs
• youtube.com: śledzenie ogromnych plików za pomocą git LFS autorstwa Tima Pettersena, Atlassian
• youtube.COM: Zarządzanie ogromnymi plikami we właściwej pamięci z Git LFS, YouTube
• youtube.com: git duże przechowywanie plików - jak pracować z dużymi plikami, youtube
• github.com/git-lfs/git-lfs/blob/master/instalacja.MD: Podręcznik instalacyjny