Git worktree: add, list, remove i prune z przykładami | We.Inc
Zbuduj dokładne polecenie git worktree add dla nowej gałęzi, istniejącej gałęzi lub odłączonego commita, a potem bezpiecznie listuj, blokuj, przenoś, usuwaj i czyść worktree.
git worktree pozwala jednemu repozytorium mieć kilka katalogów roboczych, każdy na własnej gałęzi, ze wspólnym magazynem obiektów. Uruchom git worktree add ../hotfix -b hotfix, aby utworzyć nowy katalog na nowej gałęzi, git worktree list, aby zobaczyć wszystkie, i git worktree remove ../hotfix po zakończeniu pracy. Drugi klon nie jest potrzebny.
Polecenia worktree, których potrzebujesz na co dzień
Zadanie
Polecenie
Nowy katalog na nowej gałęzi
git worktree add ../app-fix -b fix/login
Nowy katalog na istniejącej gałęzi
git worktree add ../app-review feature/cart
Tymczasowy katalog na konkretnym commicie
git worktree add --detach ../app-old v1.4.0
Zobacz wszystkie worktree
git worktree list
Usuń worktree
git worktree remove ../app-fix
Posprzątaj po katalogach usuniętych ręcznie
git worktree prune
Odkładanie zmian do stasha, przełączanie gałęzi i przebudowywanie projektu za każdym razem, gdy ktoś prosi o szybką poprawkę, to strata czasu. Worktree daje Ci drugie wypakowanie tego samego repozytorium w innym katalogu, więc długie testy, code review i pilna łatka mogą mieć każde swój katalog. Użyj generatora, aby uzyskać polecenia, a potem zajrzyj do ściągi z rzadziej używanymi podpoleceniami.
Wpisz docelowy katalog i nazwę gałęzi, a następnie wybierz nową gałąź, istniejącą gałąź lub odłączony commit.
Skopiuj polecenie add i uruchom je z wnętrza głównego katalogu repozytorium.
Pracuj w nowym katalogu jak w każdym klonie: tam commituj, wypychaj i pobieraj zmiany.
Gdy gałąź zostanie scalona, uruchom polecenie remove pokazane przez generator, a jeśli kiedyś usunąłeś katalog ręcznie, użyj prune.
Trzymaj worktree jako katalogi obok siebie, na przykład ../app-fix, aby nigdy nie trafiły do drzewa głównego katalogu repozytorium.
Każde worktree potrzebuje własnych zainstalowanych zależności i wyników builda. Zarezerwuj miejsce na dysku na node_modules w każdym katalogu.
Gałąź może być wypakowana tylko w jednym worktree naraz. Jeśli add odmawia, sprawdź w git worktree list, gdzie jest już otwarta.
Zablokuj worktree znajdujące się na dysku wymiennym poleceniem git worktree lock --reason "usb disk", aby prune go nie usunął, gdy dysk jest odłączony.
Najczęściej zadawane pytania
Czym różni się worktree od klonu?
Klon kopiuje całe repozytorium wraz z historią. Powiązane worktree współdzieli obiekty i referencje oryginalnego repozytorium i dodaje tylko nowy katalog roboczy oraz trochę metadanych, więc commity zrobione w jednym są od razu widoczne w pozostałych bez pobierania.
Czy dwa worktree mogą używać tej samej gałęzi?
Domyślnie nie. git worktree add odrzuca gałąź, która jest już wypakowana gdzie indziej, bo dwa katalogi przesuwające jedną gałąź nadpisywałyby sobie nawzajem pracę. --force to obchodzi, ale odłączony HEAD lub druga gałąź to prawie zawsze lepszy wybór.
Dlaczego git worktree remove się nie udaje?
Odmawia, gdy katalog zawiera zmodyfikowane pliki śledzone lub pliki nieśledzone, abyś nie stracił pracy. Najpierw zrób commit lub wyczyść katalog albo dodaj --force. Zablokowane worktree wymaga podwójnego --force.
Co robi git worktree prune?
Usuwa pozostałe wpisy, które git przechowuje dla worktree, których katalogi już nie istnieją, na przykład po usunięciu jednego przez rm -rf. Dodaj -n, aby najpierw zobaczyć, co zostałoby usunięte.
Jak zmienić nazwę lub przenieść katalog worktree?
Użyj git worktree move <worktree> <new-path>, aby git zaktualizował swoje wpisy. Jeśli już przeniosłeś go menedżerem plików, uruchom git worktree repair z nowej lokalizacji, aby go ponownie połączyć.
Dobre powody, by używać worktree
Klasyczne przypadki to przeglądanie pull requesta bez naruszania niedokończonej pracy, utrzymywanie wolnych testów uruchomionych na jednej gałęzi podczas kodowania na innej oraz porównywanie dwóch wersji aplikacji obok siebie.
Sprawdzają się też w narzędziach, które prowadzą kilka sesji kodowania na jednym repozytorium: każda sesja dostaje własny katalog i gałąź, więc niezacommitowane pliki jednej sesji nigdy nie przedostają się do builda innej.
Co jest współdzielone, a co nie
Wszystkie worktree współdzielą commity, gałęzie, tagi, zdalne repozytoria i większość konfiguracji. Każde ma własny HEAD, indeks i pliki robocze, więc dodanie zmian do stage w jednym katalogu nie wpływa na pozostałe.
Ignorowane pliki, takie jak .env, node_modules i katalogi builda, nie są kopiowane do nowego worktree. Skopiuj plik env samodzielnie i zainstaluj zależności przed uruchomieniem czegokolwiek.