Czy obrazy powinny być przechowywane w repozytorium git?

Czy dla rozproszonego zespołu, który używa Git i Github jako kontroli wersji, obrazy powinny być również przechowywane w repozytorium git?

W większości obrazy nie zostaną zmienione. Folder zawierający je powiększy się tylko w miarę dodawania obrazów. Niepokojące jest to, że folder obrazów może z czasem powiększać się do dużych rozmiarów przez połączenie dużych obrazów lub tylko ich wielu.

Czy jest to uważane za najlepszą praktykę? Jakie są inne możliwości udostępniania plików binarnych potrzebnych w projektach, do których rozproszony zespół ma łatwy dostęp?

Czy twoje obrazy są oryginalne, czy można je odzyskać (gwarantować?) Z innego miejsca? Czy są potrzebne do wysyłki jednostki oprogramowania zbudowanej ze źródła? Jeśli są oryginalne, potrzebują kopii zapasowej. Umieść je w swojej kontroli wersji, jeśli nigdy się nie zmienią, kara za miejsce jest taka sama jak kopia zapasowa i są tam, gdzie ich potrzebujesz.

Czy można je edytować w celu zmiany wyglądu oprogramowania, przypadkowo lub celowo? Tak - wtedy MUSZĄ być one w jakiś sposób kontrolowane, po co stosować inny sposób, gdy masz już idealne rozwiązanie. Po co wprowadzać kontrolę wersji „kopiuj i zmieniaj nazwy” z czasów ciemnych?

Widziałem, jak oryginalna grafika całego projektu „puchła”, gdy zmarł dysk twardy MacBooka projektanta grafiki, wszystko dlatego, że ktoś z nieskończoną mądrością zdecydował, że „pliki binarne nie należą do kontroli obrotów”, i projektantów graficznych (przynajmniej ten ) nie są dobre w przypadku kopii zapasowych.

To samo dotyczy wszystkich plików binarnych, które spełniają powyższe kryteria.

Jedynym powodem, aby tego nie robić, jest miejsce na dysku. Obawiam się, że 100 USD za terabajt, ta wymówka jest trochę cienka.

A czemu do licha nie? :)

Przechowywanie plików binarnych jest uważane za złą praktykę, tak, ale nigdy nie martwiłem się zbytnio o obrazy.

W najgorszym przypadku, jeśli masz tony, przechowuj je gdzie indziej lub użyj zewnętrznych lub rozszerzenia do obsługi binarnej. A jeśli obrazy nie będą tak często zmieniane, to gdzie jest problem? Nie dostaniesz dużej tłustej delty. A jeśli zostaną usunięte z czasem, tylko twój serwer trochę cierpi z powodu przechowywania historii, ale klienci nic nie zobaczą.

Moim zdaniem nie powinieneś się tym martwić - o ile nie przechowujesz ich GB.

Co mógłby zrobić, choć jest tylko Store „źródło” zdjęcia pomostów żylnych, makra latex, etc ... i mieć ostatnie obrazy generowane przez system budowania. To chyba jeszcze lepsze, jeśli możesz. Jeśli nie, to nie przejmuj się.

(To powiedziawszy, Git świeci dla plików tekstowych, ale nie jest najlepszym VCS dla zdjęć. Daj nam więcej kontekstu i danych, jeśli możesz)

Aby uzyskać dodatkowe informacje, możesz przejrzeć te pytania i odpowiedzi:

• Przechowywanie plików obrazów w SubVersion / Git
• Git vs SVN z plikami nietekstowymi
• Zarządzanie dużymi plikami binarnymi za pomocą Git i Git-submodule

To pytanie jest dość stare, ale jest to częste pytanie, które pojawia się podczas pracy z Git, i od pewnego czasu poczyniono pewne postępy w nowoczesnych rozwiązaniach do przechowywania dużych plików w repozytorium Git.

Do przechowywania dużych plików w Git dostępne są następujące projekty:

• git-annex - istnieje już od jakiegoś czasu, ale szczerze mówiąc, jego złożoność przeszkadza.
• git-media - Brak osobistych doświadczeń z tym. Wydaje się również dość skomplikowane.
• git-fit - Próba stworzenia prostszej wtyczki. Wymaga pamięci S3. Chociaż doceniam prostotę, moim głównym zmartwieniem związanym z wtyczką jest to, że jest ona dość nieznana i jest utrzymywana przez 1 osobę (pełne ujawnienie, jestem jedynym innym podmiotem odpowiedzialnym w tym czasie i dotyczyło to trywialnego problemu).
• git-lfs - Chociaż nie używałem tego zbyt często, wydaje się, że to święty Graal. Jest wspierany przez Github i jest dostępny na wszystkich swoich repozytoriach od października 2015 r ., Co komplikuje zarządzanie plikami na stronie przechowującej twoje repozytoria. Jedynym minusem jest to, że jest to dość nowe, więc poza Githubem nie ma dużego wsparcia, chociaż Gitlab ma również wsparcie , podobnie jak Gitea , a Bitbucket wspomniał o wsparciu w przyszłości .

TLDR: jeśli możesz, użyj git-lfs do przechowywania obrazów lub innych plików binarnych w git.

Całość „nie przechowuj plików binarnych w kontroli źródła” została podana z konkretnego powodu: Jeśli masz kod źródłowy, który się kompiluje, nie przechowuj faktycznej kompilacji, a tylko kod źródłowy. Obrazy i zasoby wizualne nie mają „źródła”, dlatego należy je śledzić w kontroli wersji.

Uważam, że zalecanym sposobem korzystania z Git jest użycie podmodułu (wprowadzonego w Git 1.5.3), który jest w zasadzie oddzielnym repozytorium powiązanym z głównym. Przechowujesz swoje obrazy (i inne zasoby binarne) w podmodule. Można to następnie sprawdzić w głównym repozytorium lub pozostawić, w zależności od potrzeb.

Od http://book.git-scm.com/5_submodules.html

„Obsługa podmodułów Git pozwala repozytorium zawierać, jako podkatalog, kasę zewnętrznego projektu. Podmoduły zachowują swoją tożsamość; obsługa podmodułów po prostu przechowuje lokalizację repozytorium podmodułu i zatwierdza identyfikator, więc inni programiści, którzy klonują zawierający projekt (” superprojekt ”) może łatwo sklonować wszystkie submoduły przy tej samej rewizji. Możliwe są częściowe sprawdzenie superprojektu: możesz powiedzieć Gitowi, aby nie klonował żadnego, części lub wszystkich submodułów”.

Ponadto rozmiar nie powinien być znaczącym problemem, jeśli obrazy nie zmieniają się często. Możesz także uruchamiać polecenia przycinania / zmniejszania rozmiaru, takie jak:

git gc
git gc-aggressive
git prune

Tak .

Powiedzmy, że wypuszczasz oprogramowanie w wersji 1.0. W wersji 2.0 decydujesz się na ponowne wykonanie wszystkich zdjęć z cieniami. Więc to robisz i wypuszczasz 2.0. Następnie niektórzy klienci korzystający z wersji 1.0, którzy nie mogą dokonać aktualizacji do wersji 2.0, decydują się na program w innym języku. Dają ci za to 1G $, więc mówisz pewnie. Ale w innej kulturze niektóre z twoich zdjęć nie mają sensu, więc musisz je zmienić ...

Jeśli chcesz zachować swoje obrazy w kontroli źródła, jest to łatwe, w oparciu o 1.0 wprowadzasz zmiany w obrazach (między innymi), kompilujesz, wypuszczasz. Gdybyś nie miał ich pod kontrolą źródła, miałbyś dużo trudniejszy czas, ponieważ musiałbyś znaleźć stare obrazy, zmienić je, a następnie zbudować.

Jeśli jest częścią Projektu, musi znajdować się w VCS . Jak najlepiej to osiągnąć, może zależeć od VCS lub od sposobu organizacji projektu. Może repozytorium dla projektantów i tylko wyniki z repozytorium programisty lub tylko „Źródła obrazu” (kiedyś miałem projekt z plikiem .svg i obrazami, które były generowane przez make / inscape cli).

Ale jeśli VCS nie jest w stanie sobie z tym poradzić lub staje się bezużyteczne, powiedziałbym, że nie jest to odpowiednie narzędzie do twojej pracy.

Do tej pory nie miałem problemu z umieszczeniem „zwykłych” ilości grafiki (makiet, koncepcji i grafiki stron) w projektach internetowych w git.

Jeśli przechowujesz swoje zdjęcia w SCM: tak. Bez wątpienia.

Jeśli przechowujesz swoje zdjęcia w git: staje się to trudniejsze.

git jest bardzo dobry w przypadku plików tekstowych, ale ze swej natury nie jest zbyt gorący w plikach binarnych. Będziesz mieć problemy z rozmiarem danych przesyłanych podczas klonowania lub wypychania, twoje katalogi .git będą rosły, i możesz dostać się do właściwego bałaganu z scalaniem (tj. Jak połączyć 2 obrazy!)

Jedną z odpowiedzi jest użycie podmodułów, ponieważ oznacza to, że połączenie między twoim projektem a obrazami będzie słabsze - więc nie będziesz musiał zarządzać obrazami tak, jakby były częścią twojego źródła, a jednocześnie utrzymywać je pod kontrolą i nie mieć martwi się rozgałęzieniem ich - zakładając, że podprojekt jest po prostu „płaskim” repozytorium danych, które nie przechodzą przez ten sam ruch podczas zwykłego procesu programowania.

Inną odpowiedzią jest umieszczenie ich w innym projekcie, nigdy nie rozgałęziać go i upewnić się, że każdy, kto zaangażuje się w ten projekt, popycha go natychmiast - nigdy nie pozwól 2 osobom zmienić tej samej wersji pliku - będzie to dla ciebie najtrudniejsze aspekt, ponieważ git nie jest przeznaczony do takiego nierozproszonego przepływu pracy. Będziesz musiał użyć staromodnych metod komunikacji, aby wymusić tę zasadę.

Trzecią odpowiedzią jest umieszczenie ich w zupełnie innym SCM, który jest lepiej dostosowany do pracy z obrazami.

Dodając do odpowiedzi @ haylem, zauważ, że rozmiar odgrywa w tym dużą rolę. W zależności od VCS może nie działać dobrze z mnóstwem zdjęć. Kiedy klony lub duże pchnięcia zaczynają brać całą noc, jest naprawdę za późno, ponieważ wszystkie zdjęcia są już w twoim repozytorium.

Zaplanuj duże zdjęcia i przyszły rozwój. Nie chcesz brać udziału w tym projekcie przez dwa lata i „bzdury, może repo jest trochę za duże”.

Zdecydowanie zgadzam się, że technicznie i ekonomicznie przechowywanie ich jest wykonalne. Pytanie, które chciałbym zadać, brzmi: „czy te obrazy są częścią produktu wysyłkowego czy częścią zawartości produktu wysyłkowego?” Nie dlatego, że nie możesz przechowywać treści w GIT (lub innym VCS), ale że jest to osobny problem dla osobnego VCS.