Dowiedz się, jak usunąć duży plik binarny z historii usługi Git, aby zarządzać rozmiarem sklonowanych repozytoriów

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

Usługa Git zyskała w ostatnich latach dużą popularność jako rozproszone repozytorium kodu źródłowego, które umożliwia użytkownikom pracę z pełnym repozytorium w stanie rozłączenia. Zalety usługi Git są dobrze udokumentowane, ale co się stanie, jeśli musisz "wycofać zegar" w repozytorium podstawowym? Nie jest to tak intuicyjne i wymaga zwiększonych uprawnień, zgodnie z przewidywaniami, dla czegoś, co wpływa na każdego użytkownika repozytorium.

Jak można bezpiecznie wycofać centralne repozytorium?

Scenariusz problemu

Załóżmy, że na serwerze git zatwierdzasz duży plik, taki jak wideo. W tradycyjnym systemie kodu źródłowego wygodne jest przechowywanie wszystkiego w jednym miejscu, a następnie ściąganie potrzebnych elementów. Jednak w przypadku narzędzia git całe repozytorium jest klonowane na komputer lokalny każdego użytkownika. W przypadku dużego pliku każdy użytkownik projektu będzie również musiał pobrać duże pliki. W przypadku każdego kolejnego dużego pliku zatwierdzonego na serwerze problem rośnie tylko do momentu, aż repozytorium będzie zbyt duże, aby było wydajne dla swoich użytkowników. Co gorsza, nawet jeśli usuniesz sprawcę z repozytorium lokalnego i ponownie zatwierdzsz, plik będzie nadal istniał w historii repozytorium, co oznacza, że będzie on nadal pobierany na komputer lokalny wszystkich w ramach historii.

dodawanie dużego pliku do repozytorium lokalnego

po zatwierdzeniu z repozytorium lokalnego serwer będzie również miał duży plik

Blokowanie repozytorium

Ważne

Poniższe kroki spowodują usunięcie wideo z historii gałęzi, ale plik pozostaje w historii repozytorium podczas klonowania repozytorium z usługi Azure Repos. Usunięcie plików z historii gałęzi uniemożliwia aktualizowanie plików, co spowoduje utworzenie innej wersji dużego pliku w repozytorium. Dowiedz się więcej o zarządzaniu dużymi plikami w usłudze Git i zapoznaj się z tym wpisem na blogu , aby uzyskać szczegółowe wyjaśnienie oraz rozwiązanie tego problemu podczas pracy z repozytoriami Git w Azure Repos.

Aby rozwiązać ten problem, musisz zacząć od źródła, co w tym przypadku jest repozytorium serwera. Poproś zespół o zatrzymanie commitowania do repozytorium, ale jeśli w trakcie tego procesu wystąpią dodatkowe commitowania, musisz również zapewnić ich uwzględnienie, aby nie utracić żadnych danych.

Zmiana bazy danych i wymuszanie wypychania

Jeśli nikt inny w zespole nie wprowadził żadnych zmian w repozytorium - zwykle poprzez wypychanie - możesz skorzystać z łatwego rozwiązania, w którym zasadniczo przygotowujesz lokalne repozytorium tak, aby wyglądało tak, jak chcesz (to znaczy bez dużego pliku), a następnie wymuszasz swoje zmiany na serwerze.

Uwaga: przed rozpoczęciem pracy może być konieczne sklonowanie lub naprawienie repozytorium lokalnego. Może to spowodować utratę pracy lub zmian, więc zachowaj ostrożność.

Domyślnie prawdopodobnie masz możliwość zmiany swoich lokalnych plików projektu i repozytorium oraz wypychania zmian na serwer, więc nie masz możliwości wprowadzania innych zmian, takich jak usunięcia lub przeprowadzenie rebase'u, na poziomie serwera. W związku z tym musisz uzyskać uprawnienia do projektu wymuszonego wypychania (preferowane) lub uprawnienia administratora albo znaleźć kogoś, kto je posiada i jest gotów pomóc. Aby uzyskać więcej informacji na temat uprawnień usługi Git, przejdź tutaj.

Następnie należy przeprowadzić operację rebase repozytorium.

1. Najpierw użyj polecenia git log , aby znaleźć wartości skrótu SHA najnowszych zatwierdzeń — te informacje będą potrzebne w ciągu kilku minut. Jest to spowodowane tym, że musimy znać najnowsze dobre zatwierdzenie. Te informacje można uzyskać, otwierając wiersz polecenia git i wpisując:

git log

Alternatywnie możesz uzyskać skrót SHA z wyświetlania historii gałęzi w programie Visual Studio Team Explorer.

2. Teraz otwórz wiersz polecenia usługi Git.

okno dialogowe synchronizacji

3. Znajdź skrót SHA interesujący dla Ciebie.

4. Będziesz potrzebować wartości SHA, która rozpoczyna się od "25b4"

Pamiętaj, że usługa Git używa wskaźników do określenia, gdzie w repozytorium znajduje się nagłówek lub gałąź bieżąca. W związku z tym stan repozytorium, który Cię interesuje, będzie w pewnym momencie w przeszłości. Aby "wrócić w czasie" i ustawić ten wcześniej żądany stan na nowy bieżący stan, musisz użyć polecenia git rebase:

git rebase -i <SHA hash of desired new current branch>

Przełącznik -i zapewnia nieco dodatkowe bezpieczeństwo, ponieważ spowoduje wyświetlenie historii w edytorze (Moja implementacja narzędzia Git w wierszu polecenia w systemie Windows powoduje wyświetlenie klasycznego edytora vi, który można zapamiętać, jeśli pracujesz z systemem Unix).

5. W naszym przykładzie należy wprowadzić następujące dane:

git rebase -i 25b4

6. Po uruchomieniu edytora usuń wszystkie wiersze "pick" z wyjątkiem gałęzi, którą chcesz zachować jako nową głowę. Gdy wszystko wygląda tak, jak chcesz, w viwpisz ":w<naciśnij>", aby zapisać lub "!q<naciśnij>", aby zakończyć bez zapisywania.

wiersz polecenia

Zmienisz linie, które już nie są Ci potrzebne

wiersz poleceń 25b4 drop command

7. Zmień wartość "pick" na "drop", jak pokazano, a następnie wpisz ":w" (w vi), aby zapisać i wpisz ":q!", aby rozpocząć ponowne bazowanie.

Teraz wpisz ponownie git log — problematyczna gałąź powinna być niewidoczna w dzienniku. Jeśli tak jest, możesz przystąpić do ostatniego kroku, który wymaga uprawnień administratora projektu.

git log

Zwróć uwagę, że zatwierdzenie dla dużego wideo zniknęło teraz z lokalnego repozytorium

8. Typ: git push --force

wiersz polecenia

wiersz polecenia

To polecenie wymusi zastąpienie twojego repozytorium na serwerze.

Należy zachować ostrożność, ponieważ można łatwo utracić dane na serwerze!!

pliku wideo

Zwróć uwagę, że musisz uwierzytelnić się na serwerze, aby działało

Jeśli używasz usługi Azure Repos, może być konieczne skonfigurowanie alternatywnego poświadczenia, które nie używa znaków specjalnych (takich jak "@" na adresie e-mail). Aby to zrobić, wykonaj instrukcje tutaj.

Teraz gałąź zostanie trwale usunięta z serwera, a kolejne klony i synchronizacje przez członków zespołu projektu nie będą pobierać dużych plików, które próbowano usunąć. Użytkownicy będą musieli pobrać z serwera, aby upewnić się, że są zsynchronizowani z aktualnym stanem nowego repozytorium serwera.

Jeśli użytkownicy mają nowsze zatwierdzenia

Jeśli inni użytkownicy już zobowiązali się do repozytorium serwera, należy wziąć pod uwagę dodatkowe kwestie. Chcesz usunąć gałąź zawierającą duże pliki, ale nie chcesz utracić zmian wprowadzonych przez zespół. Aby rozwiązać ten problem, po otwarciu edytora w ramach ponownego łączenia przyjrzyj się uważnie zatwierdzaniom. Upewnij się, że zatwierdzenia, które chcesz zachować, są wyświetlane w wierszach "pick"; usuń te, które chcesz usunąć, na przykład miejsce dodania dużego pliku.

Należy pamiętać, że po zrebasowaniu, inni użytkownicy w zespole również będą musieli zrebasować, aby każdy miał spójną kopię repozytorium na serwerze. Problem dotyka wszystkich i należy go unikać. W związku z tym, jeśli musisz usunąć push, jak tutaj wspomniano, ważne jest, aby koordynować działania z zespołem. Aby uzyskać szczegółowe informacje na temat ponownego łączenia, zapoznaj się z oficjalną dokumentacją ponownego łączenia tutaj.

Kluczem jest upewnienie się, że wiesz, które zatwierdzenia są wymagane i niepożądane. Zapoznaj się z dziennikiem git lub historią w IDE (takim jak Visual Studio) i skrupulatnie zanotuj skróty SHA do zachowania oraz te do odrzucenia.

W scenariuszach, w których duży plik znajduje się od jakiegoś czasu i nastąpiły kolejne gałęzie i scalania, może być możliwe usunięcie pliku przy użyciu przełącznika git filter-branch. Jeśli chcesz wykonać tę próbę, postępuj zgodnie z instrukcjami tutaj.

Zagadnienia dotyczące najlepszych rozwiązań

Aby zaoszczędzić dużo pracy, należy upewnić się, że duże pliki od początku pozostają poza głównym repozytorium. Mając to na uwadze, oto kilka najlepszych rozwiązań dla zespołu, które należy wziąć pod uwagę:

Czy

• Często zatwierdzaj zmiany. Zawsze można je poprawić później za pomocą squasha lub rebase'owania.
• Używaj gałęzi do izolowania zmian. Te gałęzie są tanie i prywatne, a łączenie jest proste. Możesz również utworzyć kopię zapasową zmian w gałęzi, wypychając ją na serwer.
• Podczas publikowania gałęzi tematu należy użyć konwencji nazewnictwa. Nadaj gałęzi nazwę "users/<alias>/<branchname>". Pomoże to zgrupować gałęzie i ułatwić innym osobom identyfikację "właściciela".
• Pamiętaj, aby zpushować zmiany. Commit != Checkin. (Commit + Push) == Checkin.
• Rozważ użycie .gitignore dla dużych plików binarnych, aby nie zostały dodane do repozytorium w pierwszej kolejności — więcej informacji tutaj.
• Rozważ użycie kontroli wersji pakietów NuGet lub TFS do przechowywania dużych plików binarnych.

Czego nie robić

• Nie wykonuj rebase po wypchnięciu. Przebazowywanie wypychanych zatwierdzeń w narzędziu Git może być problematyczne, ponieważ zmusza innych użytkowników repozytorium do przebazowywania swoich lokalnych zmian, co z reguły spotyka się z ich niezadowoleniem. Ponowne łączenie wypchniętych zatwierdzeń we własnej gałęzi osobistej, nawet w przypadku wypchnięcia, nie jest znaczącą transakcją, chyba że inne osoby ściągają te zatwierdzenia.
• Nie zatwierdzaj plików binarnych w repozytorium. Git nie kompresuje plików binarnych w taki sposób, jak robi to TFVC, a ponieważ wszystkie repozytoria mają całą historię, zatwierdzanie plików binarnych oznacza znaczne zwiększenie rozmiaru.

Podsumowanie

Czasami niepożądane elementy, takie jak duże pliki, są dodawane do repozytorium i muszą zostać usunięte, aby repozytorium było czyste i lekkie. Można to zrobić, porządkując swoje lokalne repozytorium przy użyciu polecenia git rebase, a następnie nadpisując repozytorium serwera używając repozytorium lokalnego przy użyciu polecenia git push --force.

Autorzy: Edward Fry i Jesse Houwing | Skontaktuj się z autorami i ALM | Usługa DevOps Rangers tutaj

c) 2015 Microsoft Corporation. Wszystkie prawa zastrzeżone. Ten dokument jest dostarczany "as-is". Informacje i opinie wyrażone w tym dokumencie, w tym adres URL i inne odwołania do stron internetowych, mogą zostać zmienione bez uprzedzenia. Ryzyko korzystania z niniejszego dokumentu ponosi użytkownik.

Ten dokument nie zapewnia użytkownikowi żadnych praw do własności intelektualnej w żadnym produkcie firmy Microsoft. Możesz skopiować ten dokument i użyć go do celów wewnętrznych, referencyjnych.