"To zależy." Do normalnego śledzenia rozwoju, nie. W przypadku wdrożeń chmurowych i DevOps jest to jednak często wygodne, a nawet wymagane.
Przez większość czasu
@ptyx jest poprawny . Rzeczywiście, jego „nie” można powiedzieć nieco bardziej zdecydowanie. Coś w stylu „Nie. Nie! OMG NIE! ”
Dlaczego nie przechowywać zminimalizowanych lub skompresowanych zasobów w systemie kontroli źródła, takim jak Git?
Można je niemal w prosty sposób zregenerować w procesie kompilacji w locie z kodu źródłowego. Przechowywanie skompresowanych zasobów polega zasadniczo na dwukrotnym przechowywaniu tej samej logicznej zawartości. Narusza to zasadę „nie powtarzaj się” (inaczej DRY ).
Mniej filozoficznym, ale bardziej praktycznym powodem jest to, że zminimalizowane / zoptymalizowane zasoby mają bardzo słabą ściśliwość, gdy są przechowywane w Git. Systemy kontroli źródła działają poprzez rozpoznawanie zmian („delt”) między różnymi wersjami każdego przechowywanego pliku. Aby to zrobić, „różnicują” najnowszy plik z poprzednią wersją i używają tych delt, aby uniknąć przechowywania pełnej kopii każdej wersji pliku. Ale transformacje dokonane w kroku minimalizacji / optymalizacji często usuwają podobieństwa i punkty trasy wykorzystywane przez algorytmy różnicowe / różnicowe . Najbardziej trywialnym przykładem jest usuwanie podziałów linii i innych białych znaków; wynikowy zasób to często tylko jedna długa linia. Wiele części procesu budowania sieci - narzędzia takie jak Babel , UglifyJS , Browserify ,Mniej , a Sass / SCSS - agresywnie przekształcają aktywa. Ich produkcja jest zaburzona; niewielkie zmiany danych wejściowych mogą prowadzić do poważnych zmian produkcji. W rezultacie algorytm różnicowy często wierzy, że za każdym razem widzi prawie zupełnie inny plik. W rezultacie Twoje repozytoria będą rosły szybciej. Twoje dyski mogą być wystarczająco duże, a sieci wystarczająco szybkie, co nie stanowi poważnego problemu, szczególnie jeśli wartość podwójnego przechowywania zminimalizowanych / zoptymalizowanych zasobów była warta - chociaż w oparciu o punkt 1, dodatkowe kopie mogą być w 100% bezcelowe nadąć.
Istnieje jednak poważny wyjątek: wdrożenia DevOps / w chmurze. Wielu dostawców chmury i zespoły DevOps używają Git i podobnych nie tylko do śledzenia aktualizacji programistycznych, ale także do aktywnego wdrażania swoich aplikacji i zasobów na serwerach testowych i produkcyjnych. W tej roli zdolność Gita do skutecznego określania „jakie pliki się zmieniły?” jest równie ważne, jak jego bardziej szczegółowa zdolność do określania „co zmieniło się w każdym pliku?” Jeśli Git musi wykonać prawie pełną kopię pliku dla zminimalizowanych / zoptymalizowanych zasobów, zajmuje to trochę dłużej niż w innym przypadku, ale to nic wielkiego, ponieważ nadal wykonuje doskonałą pracę, pomagając uniknąć kopii „każdego pliku w projekcie” na każdym cykl wdrażania.
Jeśli używasz Git jako mechanizmu wdrażania, przechowywanie zminimalizowanych / zoptymalizowanych zasobów w Git może zmienić się z „nie!” pożądane. Rzeczywiście może to być wymagane, powiedzmy, jeśli brakuje solidnych możliwości kompilacji / przetwarzania końcowego na serwerach / usługach, na których wdrażasz. (Jak podzielić segmenty zasobów programistycznych i wdrożeniowych w tym przypadku, jest osobną puszką robaków. Na razie wystarczy wiedzieć, że można nimi zarządzać na kilka sposobów, w tym za pomocą jednego zunifikowanego repozytorium, wielu gałęzi, podrepozytorów, a nawet wielu nakładających się repozytoriów. )
/dev/null.