dvcs - czy „klonowanie do rozgałęzienia” jest powszechnym przepływem pracy?

Niedawno rozmawiałem o dvcs ze współpracownikiem, ponieważ nasze biuro zaczyna rozważać przejście z TFS (jesteśmy sklepem MS). Byłem bardzo zdezorientowany, ponieważ powiedział, że chociaż używa Mercuriala, nie słyszał o poleceniu „gałęzi” lub „kasy”, a te terminy były mu nieznane. Po zastanowieniu się, jak to możliwe, że nie wiedział o nich i wyjaśnieniu, w jaki sposób gałęzie dvcs działają „w miejscu” na twoich lokalnych plikach, był całkiem zdezorientowany.

Wyjaśnił, że podobnie jak TFS, kiedy chce utworzyć „gałąź”, robi to poprzez klonowanie, więc ma całą kopię swojego repozytorium. Wydawało mi się to bardzo dziwne, ale korzyść, którą muszę przyznać, polega na tym, że możesz przeglądać lub pracować na dwóch gałęziach jednocześnie, ponieważ pliki są osobne.

Podczas przeszukiwania tej witryny, aby sprawdzić, czy o to pytano, zobaczyłem komentarz, że wiele zasobów internetowych promuje tę metodologię „klonowania do gałęzi”, ku przerażeniu plakatu. Czy to faktycznie jest powszechne w społeczności dvcs? A jakie są zalety i wady płynięcia tą drogą? Nigdy bym tego nie zrobił, ponieważ nie muszę widzieć wielu gałęzi jednocześnie, przełączanie jest szybkie i nie potrzebuję wszystkich klonów wypełniających mój dysk.

Poza ogólną zaletą / wadą widzenia obu gałęzi, myślę, że jest to specyficzna zaleta Mercurial.

Jeśli sklonujesz, aby utworzyć gałąź, możesz usunąć klon później, jeśli nie chcesz zachować zmian. Jeśli zdecydujesz się je scalić, to fakt, że postanowiłeś oddzielić swoje zmiany w ten sposób, nie jest widoczny dla nikogo innego.

Z drugiej strony, jeśli użyjesz hg branchdo utworzenia nowej nazwanej gałęzi, nazwa gałęzi jest zapisywana w historii po zatwierdzeniu, jest widoczna dla wszystkich innych i musi być dość unikalna, aby uniknąć potencjalnego pomyłki później. Może to nie być odpowiednie, jeśli twoja gałąź jest przeznaczona do opracowania eksperymentalnej funkcji lub zmiany, która może okazać się niewielka.

Jeśli używasz nazwanych gałęzi do utrzymywania wydanych wersji oprogramowania, a także używasz ich do opracowywania krótkoterminowych funkcji lub poprawek błędów, łatwo się pomylić, ponieważ nie ma sposobu (oprócz konwencji nazewnictwa) na oddzielenie tych dwóch rodzajów gałęzi.

http://mercurial.selenic.com/wiki/StandardBranching wyjaśnia to bardziej szczegółowo. Warto również wspomnieć, że od wersji Mercurial 1.8 można utworzyć zakładkę ( hg bookmark) - jednorazową nazwę dla krótkotrwałej gałęzi. Zakładki można przesuwać, wyciągać, przenosić i usuwać.

Za każdym razem, gdy dokonujesz zatwierdzenia w DVCS, technicznie tworzysz gałąź w historii, za każdym razem, gdy wypychasz ją z powrotem do błogosławionego repozytorium, integrujesz ją z powrotem, oto interesująca część:

• Jeśli nikt nie dokonał zmiany podczas zatwierdzenia, nie będzie wyglądać jak gałąź w DAG (skierowany wykres acykliczny)
• Jeśli ktoś dokonał zmiany podczas twojego zatwierdzenia, będzie to wyglądać jak gałąź w DAG, tylko bez nazwy

Pamiętasz przycisk „widelec” w Bitbucket / github ?, rozwidlenie można uznać za synonim rozgałęzienia, a to, co robi przycisk „widelec”, to po prostu klon tego repozytorium na Twoim koncie.

Jedyną zaletą „klonowania do gałęzi” jest możliwość jednoczesnej pracy w dwóch punktach historii, a jak na ironię dla współpracownika, jest to wspólny proces pracy dla różnych gałęzi w tym samym czasie (bez konieczności przechodzenia tam i z powrotem ).

Powiedz współpracownikowi, aby nauczył się rozgałęziać , jest to bardzo łatwe, tutaj masz samouczek:

D:\>mkdir lol

D:\>cd lol

D:\lol>hg init

D:\lol>hg branch
default

D:\lol>touch lol

D:\lol>hg add lol

D:\lol>hg commit -m "lol"

D:\lol>hg branch lol
marked working directory as branch lol
(branches are permanent and global, did you want a bookmark?)

D:\lol>hg branches
default                        0:35d562fafaf2

D:\lol>echo "lol" > lol

D:\lol>hg commit -m "New lol branch"

D:\lol>hg branches
lol                            1:9384f923e78d
default                        0:35d562fafaf2 (inactive)

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg update lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg merge lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

D:\lol>hg commit -m "lol merge"

D:\lol>hg branch
default

D:\lol>hg update lol
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

„Klonowanie do gałęzi” ma sens, gdy pracujesz jednocześnie w różnych gałęziach lub gdy chcesz wypróbować eksperyment bez tworzenia stałej gałęzi w historii i nadal być w stanie zintegrować ją z już istniejącą gałęzią .

Ja osobiście nie lubię tej praktyki i wolę robić gałęzie i zamykać je w razie potrzeby. Oto jak to robisz:

D:\lol>hg branches
default                        2:46420aca1612
lol                            1:9384f923e78d (inactive)

D:\lol>hg branch
lol

D:\lol>hg commit --close-branch -m "Obai, glorious lol branch"

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branch
lol

D:\lol>hg update default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branches --closed
default                        2:46420aca1612
lol                            3:4b79c577e029 (closed)

Mam nadzieję, że rozwiąże to wątpliwości rozgałęziające się w DVCS, tutaj gałęzie nie są już przerażające.

Osobiście nie martwiłbym się, że kod zapełni mój dysk ... po pierwsze, to po prostu kod, a po drugie, nie będziesz przechowywać wszystkich swoich klonów na zawsze.

Metodologia ta jest promowana w wielu zasobach online, szczególnie w przypadku Hg. Nigdy nie widziałem, aby był używany w produkcji, w środowiskach CI o wiele bardziej powszechne jest posiadanie krótkotrwałych gałęzi funkcji niż dodatkowych klonów repozytorium. Nie widzę korzyści z robienia tego, jeśli cokolwiek sprawi, że twoja historia będzie bardziej zagmatwana, nie mniej, a także nic ci nie da. Jeśli chcesz spojrzeć na swój nowy kod obok starego kodu, możesz użyć narzędzia porównywania / scalania, aby spojrzeć na dwa zatwierdzenia obok siebie, z dodatkową zaletą polegającą na podświetleniu zmian.