Pomóż zrozumieć zalety rozgałęzienia w Mercurial

Question

Starałem się zrozumieć, jak rozgałęzienie jest korzystne. Nie mogę przeprowadzić repozytorium z 2 głowami lub 2 oddziałami ... dlaczego więc miałbym ich potrzebować/używać?

Answer 1

Przede wszystkim możesz naciskać nawet dwoma głowami, ale ponieważ prawdopodobnie nie chcesz tego robić, domyślnym zachowaniem jest zapobieganie temu. Możesz jednak zmusić push, aby przejść.

Teraz, jeśli chodzi o rozgałęzianie, zróbmy prosty scenariusz w niezespolonym systemie kontroli wersji, takim jak Subversion.

Załóżmy, że masz kolegę, który pracuje w tym samym projekcie co ty. Obecny najnowszy zestaw zmian w repozytorium Subversion to wersja 100, zarówno aktualizuje się do tego lokalnie, tak, że teraz oboje macie te same pliki.

Ok, teraz twój kolega już pracował nad jego zmianami od kilku godzin, a więc popełnia. Spowoduje to przeniesienie centralnego repozytorium do wersji 101. Wciąż jesteś na wersji 100 lokalnie i wciąż pracujesz nad swoimi zmianami.

W pewnym momencie kończysz, a chcesz zatwierdzić, ale Subversion ci nie pozwoli. Mówi, że musisz najpierw zaktualizować, aby rozpocząć proces aktualizacji.

Proces aktualizacji chce wprowadzić zmiany i udawać, że zacząłeś od wersji 101 zamiast 100. Jeśli twoje zmiany nie są sprzeczne z tym, co zostało zrobione przez twojego kolegę, wszystko jest w porządku, ale jeśli twoje zmiany to są w konflikcie, masz problem.

Teraz musisz scalić swoje zmiany ze zmianami, a wszystko może pójść na marne. Na przykład możesz zakończyć scalanie jednego pliku OK, drugi plik OK, lub tak myślisz, a następnie trzeci plik, i nagle odkryjesz, że masz trochę błędnych danych, byłoby lepiej scalić drugi plik inaczej.

O ile nie wykonałeś kopii zapasowej zmian przed aktualizacją, a wcześniej czy później zapomnisz, masz problem.

Obecnie powyższy scenariusz jest dość powszechny. Cóż, być może nie część łącząca, to zależy od tego, ile osób pracuje w tym samym obszarze lub plików w tym samym czasie, ale część "musi zaktualizować przed popełnieniem" jest dość powszechna w przypadku Subversion.

Jak działa Mercurial?

Cóż, Mercurial zobowiązuje się lokalnie, nie komunikuje się z żadnym repozytorium, więc nie powstrzyma cię od popełnienia.

Spróbujmy więc powtórzyć powyższy scenariusz, właśnie tym razem w Mercurial.

changeset tipmost w zdalnym repozytorium jest rewizja 100. Oboje są klonowane to w dół, a ty zarówno rozpoczęciem pracy na zmiany, od rewizji 100.

Twój kolega kończy swoje zmiany i zobowiązuje, lokalnie. Następnie przesuwa swój zestaw zmian do centralnego repozytorium, przenosząc końcówkę do wersji 101.

Następnie wypełniasz zmiany i zatwierdzasz, również lokalnie, a następnie chcesz nacisnąć, ale pojawi się komunikat o błędzie już odkrył i pyta.

Jak to się zmienia?

Cóż, twoje zmiany są teraz zatwierdzone, nie ma sposobu, chyba że spróbuj naprawdę ciężko przypadkowo je zgubić lub zniszczyć.

Oto 3 repozytoriów w zabawach i ich aktualny stan:

Colleague  ---98---99---100---A 

Central   ---98---99---100---A 

You    ---98---99---100---B 

Jeśli było wcisnąć i pozwolono, aby to zrobić (lub zmusić przeforsować), centralnym repozytorium będzie wyglądać następująco:

Central   ---98---99---100---A 
           \ 
           +--B 

Dwie głowy. Jeśli twój kolega wyciągnął teraz, z którym powinien kontynuować pracę? To pytanie jest powodem, dla którego Mercurial domyślnie uniemożliwi ci to.

Więc zamiast ciągnąć, otrzymasz powyższy stan w swoje własne repozytorium.

Innymi słowy, możesz wybrać wpływ na własne repozytorium i utworzyć tam wiele głowic, ale nie musisz narzucać tego problemu nikomu innemu,.

Następnie łączysz, ten sam typ operacji, który musiałeś wykonać w Subversion, z tym wyjątkiem, że twój zestaw zmian jest bezpieczny, został popełniony, a ty przypadkiem nie uszkodzisz go ani nie zniszczysz. Jeśli, w połowie scalania, chcesz zacząć od nowa, możesz, nic nie stracić, nie zaszkodzić.

Po scaleniu, lokalnym repozytorium wygląda następująco:

You    ---98---99---100---A----M 
           \  /
           +--B--+ 

To jest teraz bezpieczny do pchania, a jeśli twój kolega teraz ciągnie, wie, że musi kontynuować z changeset m, jeden która połączyła jego i twoje zmiany.

Powyższy opis dotyczy sytuacji rozproszonych Mercurials.

Można również nazwać gałęzie, aby stały się bardziej trwałe. Na przykład, możesz chcieć nazwać gałąź "stabilną", aby zasygnalizować, że wszelkie zmiany w tej gałęzi zostały dokładnie przetestowane i są bezpieczne do wydania klientom lub do wdrożenia. Następnie scalilibyście zmiany w tej gałęzi dopiero po zakończeniu tych testów.

Natura jest jednak taka sama, jak powyższy opis. Ilekroć więcej niż jedna osoba pracuje nad projektem z Mercurial, uzyska dostawać gałęzie, i to dobrze.

Answer 2

Za każdym razem, gdy dokonywany jest więcej niż jeden klon repo i dokonywane są zatwierdzenia w tych klonach, rozgrywają się rozgałęzienia, niezależnie od tego, czy je nazwiesz, używając polecenia hg branch, czy też nie. Moja filozofia jest taka, że ​​równie dobrze możesz im nadać imię. To sprawia, że ​​rzeczy stają się mniej zagmatwane.

dobre wyjaśnienie rtęci branżach: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/