Do czego miałbym używać git-worktree?

Przeczytałem post Githuba na git-worktree . Piszą:

Załóżmy, że pracujesz w repozytorium Git w gałęzi o nazwie feature, gdy użytkownik zgłasza błąd o wysokim priorytecie master. Najpierw tworzysz połączone drzewo robocze z nową gałęzią, hotfixsprawdzane względem mistrza […] Możesz naprawić błąd, wcisnąć poprawkę i utworzyć żądanie ściągnięcia.

Kiedy pracuję nad gałęzią o nazwie funkcja i zgłaszany jest jakiś pilny błąd w programie głównym, zwykle ukrywam wszystko, nad czym pracuję, i tworzę nowy oddział. Kiedy skończę, mogę kontynuować pracę. To bardzo prosty model, pracuję tak od lat.

Z drugiej strony korzystanie z git-worktree ma swoje własne ograniczenia:

Na przykład niedozwolone jest wyewidencjonowanie tej samej gałęzi w dwóch połączonych działających drzewach jednocześnie, ponieważ pozwoliłoby to na dokonanie zmian w jednym działającym drzewie w celu zsynchronizowania drugiego.

Dlaczego miałbym wybrać bardziej skomplikowany przepływ pracy dla problemu, który został już rozwiązany?

Czy jest coś w git-worktreetym zakresie, czego nie można było zrobić wcześniej i to uzasadnia tę nową, złożoną funkcję?

Dla mnie git worktree to największa poprawa od dawna. Pracuję nad rozwojem oprogramowania dla przedsiębiorstw. Tam często zachowuje się stare wersje, takie jak wydane 3 lata temu. Oczywiście masz gałąź dla każdej wersji, dzięki czemu możesz łatwo przejść do niej i naprawić błąd. Jednak przełączanie jest kosztowne, ponieważ w międzyczasie całkowicie zrestrukturyzowałeś repozytorium i być może zbudowałeś system. Jeśli się przełączysz, twoje IDE oszaleje, próbując dostosować ustawienia projektu.

Dzięki worktree możesz uniknąć ciągłej rekonfiguracji. Sprawdź te stare gałęzie w osobnych folderach, korzystając z drzewa roboczego. Dla każdego oddziału masz niezależny projekt IDE.

Oczywiście można to było zrobić w przeszłości przez kilkakrotne klonowanie repozytorium i do tej pory takie było moje podejście. Oznaczało to jednak także marnowanie miejsca na dysku twardym i gorsze konieczność kilkakrotnego pobrania tych samych zmian z repozytorium.

Widzę w tym pewne zastosowania.

Jeśli masz zestaw testowy, który działa przez długi czas, wyobraź sobie godziny, a uruchomisz go skutecznie blokuje kopię roboczą do czasu zakończenia testów. Zmiana gałęzi podczas tych testów złamałaby je w sposób trudny do zrozumienia.

Dzięki temu git-worktreemogłem uruchomić drugi pomysł na inny dział, który tam pracuje.

Ponadto, kiedy przechodzę do innej gałęzi, aby przeprowadzić szybkie dochodzenie, moje IDE uważa, że ​​wiele plików nagle się zmieniło i zindeksuje wszystkie te zmiany, tylko po to, aby ponownie je zindeksować, kiedy wracam.

Trzecim przypadkiem użycia byłoby porównanie plików przy użyciu innych narzędzi niż git-diff, jak zwykle diff, między dwoma katalogami zamiast dwóch gałęzi.

Jednym z oczywistych zastosowań jest jednoczesne porównanie zachowania (nie źródła) różnych wersji - na przykład różnych wersji strony internetowej lub po prostu strony internetowej.

Próbowałem tego lokalnie.

• utwórz katalog page1.

• w środku utwórz katalog srci git initto.

• w srcstworzenie page1.htmlz małą zawartością i zobowiązać go.

• $ git branch ver0

• $ git worktree add ../V0 ver0

• w srcmaster dodaj więcej tekstu page1.htmli zatwierdź go.

• $ git branch sty1

• edytuj page1.htmlw sty1gałęzi (dodaj charakterystyczny styl CSS) i dodaj zatwierdz.

• $ git worktree add ../S1 sty1

Możesz teraz używać przeglądarki internetowej do jednoczesnego otwierania i przeglądania tych 3 wersji:

• ..\page1\src\page1.html // cokolwiek git ma jako prąd

• ..\page1\V0\page1.html // początkowa wersja

• ..\page1\S1\page1.html // wersja w stylu eksperymentalnym

1. Istnieją uzasadnione powody, dla których możesz chcieć / potrzebować wielu drzew roboczych w systemie plików jednocześnie.

   • manipulowanie pobranymi plikami, gdy trzeba wprowadzić zmiany w innym miejscu (np. kompilacja / testowanie)

   • różnicowanie plików za pomocą zwykłych narzędzi do porównywania

   • podczas konfliktów scalania często chcę nawigować po kodzie źródłowym, ponieważ znajduje się on po stronie źródłowej, podczas rozwiązywania konfliktów w plikach.

   • Jeśli musisz często przełączać się w jedną i drugą stronę, tracisz czas na sprawdzanie i sprawdzanie, że nie musisz zajmować się wieloma stopniami roboczymi.

   • mentalny koszt przełączania kontekstu mentalnego między gałęziami za pomocą skrytki git nie jest tak naprawdę wymierny. Niektóre osoby uważają, że ukrywanie kosztu jest kosztem psychicznym, którego nie ma po prostu otwierając pliki z innego katalogu.

2. Niektóre osoby pytają „dlaczego nie zrobić wielu lokalnych klonów”. Prawdą jest, że z flagą „--local” nie musisz się martwić o dodatkowe wykorzystanie miejsca na dysku. To (lub podobne pomysły) zrobiłem do tego momentu. Zalety funkcjonalne połączonych drzew roboczych w porównaniu z lokalnymi klonami to:

   1. W przypadku lokalnych klonów dodatkowe stoły robocze (które znajdują się w lokalnych klonach) po prostu nie mają dostępu do początkowych ani odgałęzień. „Pochodzenie” w klonie nie będzie takie samo jak „pochodzenie” w pierwszym klonie.

      • Bieganie git log @{u}..lub git diff origin/feature/other-featuremoże być bardzo pomocne, a albo nie są już możliwe, albo trudniejsze. Pomysły te są technicznie możliwe w przypadku lokalnych klonów za pomocą zestawu obejść, ale każde obejście, które można zrobić, jest wykonywane lepiej i / lub prościej za pośrednictwem powiązanych ze sobą drzew roboczych.

   2. Możesz udostępniać referencje między stołami roboczymi. Jeśli chcesz porównać lub pożyczyć zmiany z innego lokalnego oddziału, teraz możesz.

tl; dr: Za każdym razem, gdy chcesz mieć jednocześnie sprawdzone dwa drzewa robocze z dowolnego powodu, git-worktreejest to szybki i zajmujący mało miejsca sposób.

Jeśli utworzysz inne środowisko robocze, większość części repozytorium (tj. .git) Zostanie udostępniona, co oznacza, że ​​jeśli utworzysz gałąź lub pobierzesz dane, gdy jesteś w jednym drzewie roboczym, będzie on również dostępny z dowolnego innego drzewa roboczego. Załóżmy, że chcesz uruchomić pakiet testowy na gałęzi foo bez konieczności wypychania go gdzieś w celu sklonowania go i chcesz uniknąć kłopotów z klonowaniem repozytorium lokalnie, użycie git-worktreejest dobrym sposobem na utworzenie tylko nowej kasy jakiegoś stanu w oddzielne miejsce, tymczasowo lub na stałe. Podobnie jak w przypadku klonu, wszystko, co musisz zrobić, gdy to zrobisz, to usuń go, a odwołanie do niego zostanie po pewnym czasie wyrzucone.

Początkowo natknąłem się na to pytanie, zastanawiając się, do czego można wykorzystać te fantazyjne stoły robocze. Od tego czasu zintegrowałem je z moim procesem pracy i pomimo początkowego sceptycyzmu uznałem je za całkiem przydatne.

Pracuję na dość dużej podstawie kodu, co zajmuje sporo czasu. Zazwyczaj mam na komputerze bieżącą gałąź programistyczną wraz z gałęzią funkcji, nad którą obecnie pracuję, oraz gałąź główną, która reprezentuje bieżący stan systemu na żywo.

Jedną z największych korzyści dla mnie jest oczywiście to, że nie muszę rekompilować całej rzeczy za każdym razem, gdy zmieniam gałęzie (czyli drzewa robocze). Fajnym efektem ubocznym jest to, że mogę przejść do drzewa programowania, zrobić tam rzeczy, zmienić katalog na drzewo pracy dla mojej bieżącej gałęzi funkcji, a następnie dokonać zmiany bazy bez konieczności ciągnięcia.

Mam dość nietypowy: programuję systemy Windows i Linux na tym samym komputerze . Mam VirtualBox z systemem Linux wewnątrz mojego systemu Windows. VirtualBox montuje niektóre katalogi Windows i używa ich bezpośrednio w komputerze z systemem Linux. To pozwala mi używać systemu Windows do zarządzania plikami, ale budować w systemie Linux. Jest to projekt wieloplatformowy, więc opiera się zarówno na systemie Windows, jak i Linux z tej samej struktury katalogów.

Problem polega na tym, że systemy kompilacji Linux i Windows ulegają awarii, gdy są używane w tym samym katalogu; istnieją pewne skomplikowane kroki kompilacji pobierania bibliotek itp., które używają tych samych nazw katalogów. Wersja systemu kompilacji dla systemu Windows pobiera biblioteki specyficzne dla systemu Windows, a wersja systemu kompilacji dla systemu Linux pobiera biblioteki specyficzne dla systemu Linux.

W idealnym świecie system kompilacji zostałby zmodyfikowany, aby systemy Windows i Linux mogły współistnieć w katalogu, ale na razie problem jest rozwiązywany za pomocą drzew roboczych. Folder „Linux” może generować artefakty kompilacji specyficzne dla systemu Linux, a folder „Windows” może generować artefakty kompilacji systemu Windows. Chociaż nie jest to idealne rozwiązanie, stanowi dobrą przerwę w oczekiwaniu na usunięcie błędów systemu kompilacji.

Trzeba przyznać, że nie stworzono do tego drzewa roboczego; Muszę zachować wersję Windows i Linuksa w osobnych gałęziach, mimo że naprawdę wolałbym, aby znajdowały się w tej samej gałęzi. Mimo to wykonuje swoją pracę i jest dość niekonwencjonalnym przypadkiem oszczędzania dnia przez środowisko pracy.

W nowym projekcie stworzyłem funkcję. Ale niektóre specyfikacje zawiodły. Aby porównać wyniki z masterutworzyłem work-treerepozytorium. Porównywałem wyniki krok po kroku w kodzie uruchomieniowym, aż zrozumiałem, co poszło nie tak.

używam git worktree do rozwoju uczenia maszynowego.

Mam główny kod funkcjonalny, a następnie chcę podzielić gałęzie różnych eksperymentów (różne algorytmy i różne hiperparametry). git worktreepozwala mi zintegrować dvc z różnymi wersjami mojego kodu specjalizującymi się w różnych algorytmach. Po przeprowadzeniu wszystkich zadań szkoleniowych oceniam końcowe wskaźniki i łączę się, aby opanować najlepszą gałąź / model.