Kiedy należy się rozgałęzić?

Kiedy pracujesz z systemem SCM, kiedy powinieneś rozgałęzić się?

Istnieje kilka zastosowań rozgałęziania. Jednym z najczęstszych zastosowań jest oddzielanie projektów, które kiedyś miały wspólną bazę kodu. Jest to bardzo przydatne do eksperymentowania z kodem bez wpływu na główny tor.

Ogólnie można zobaczyć dwa typy gałęzi:

• Gałąź funkcji: Jeśli dana funkcja jest na tyle uciążliwa, że ​​nie chcesz, aby na wczesnym etapie miała to wpływ na cały zespół programistów, możesz utworzyć gałąź, w której będziesz wykonywać tę pracę.

• Gałąź poprawek: Podczas gdy rozwój jest kontynuowany w głównym pniu, można utworzyć gałąź poprawek, aby przechowywać poprawki do najnowszej wydanej wersji oprogramowania.

Możesz być zainteresowany przeczytaniem następującego artykułu, który wyjaśnia zasady rozgałęziania i kiedy ich używać:

• Ned Batchelder - Szybki start w gałęzi Subversion

Ogólnie rzecz biorąc, głównym celem rozgałęziania (VCS - funkcji systemu kontroli wersji) jest osiągnięcie izolacji kodu .

Masz co najmniej jedną gałąź, która może wystarczyć do sekwencyjnego rozwoju i jest używana do wielu zadań zapisywanych (zatwierdzanych) w tej samej unikalnej gałęzi.

Ale ten model szybko pokazuje swoje granice:

Kiedy masz wysiłek programistyczny (refaktoryzacja, ewolucja, poprawki błędów, ...) i zdajesz sobie sprawę, że nie możesz bezpiecznie wprowadzić tych zmian w tej samej gałęzi, co Twoja obecna gałąź programistyczna (ponieważ złamałbyś API lub wprowadził kod, który zepsułby wszystko), następnie trzeba inny oddział.
(Aby wyodrębnić ten nowy kod dla starszego, mimo że dwa zestawy kodów zostaną później połączone)

Oto twoja odpowiedź:
powinieneś rozgałęziać się, gdy nie możesz kontynuować i odnotować dwóch wysiłków rozwojowych w jednej gałęzi.
(bez strasznie skomplikowanej historii do utrzymania).

Gałąź może być przydatna, nawet jeśli jesteś jedyną osobą pracującą nad kodem źródłowym lub jeśli jest ich wielu.
Ale nie powinieneś tworzyć „jednej gałęzi na programistę”:
celem „izolacji” jest odizolowanie wysiłku programistycznego (zadanie, które może być tak ogólne, jak „opracujmy następną wersję naszego oprogramowania” lub tak szczegółowe, jak „naprawmy błąd 23 ”),
aby nie izolować„ zasobu ” .

(gałąź o nazwie „VonC” nic nie znaczy dla innego programisty: Co jeśli „VonC” opuści projekt? Co masz z nią zrobić?
gałąź o nazwie „bugfix_212” może być interpretowana w kontekście np. systemu śledzenia błędów i każdy programista może go użyć, mając przynajmniej jakieś pojęcie o tym, co ma z nim zrobić)

Gałąź nie jest tagiem (SVN to system wersji, który próbuje zaproponować funkcje wersjonowania, takie jak rozgałęzianie i tagowanie przez katalogi za pomocą taniej kopii pliku: to nie oznacza, że ​​tag jest odgałęzieniem)

Zdefiniowanie gałęzi oznacza również zdefiniowanie przepływu pracy przy scalaniu : musisz wiedzieć, gdzie scalić gałąź, kiedy skończysz.
W tym celu rozdział 7 książki Practical Perforce (Laura WINGERD - O'Reilly) jest dobrym wprowadzeniem (agnostyk VCS) do łączenia przepływu pracy między różnymi rodzajami gałęzi: "" Jak rozwija się oprogramowanie "(pdf)

Definiuje termin codeline (gałąź, która rejestruje znaczące etapy ewolucji kodu, albo poprzez tagi w określonych punktach, albo poprzez ważne scalenie z powrotem do gałęzi)

Przedstawia model mainline (centralna linia kodów do zapisywania wydań) i opisuje różne cele rozgałęziania:

• Aktywne strumienie rozwoju : trwała linia kodowa, gdy mają miejsce kolejne różne zmiany
• gałęzie zadań : krótkotrwałe gałęzie dla bardziej konkretnego zadania (naprawianie błędów jest klasyczne, ale możesz także zdefiniować gałąź dla operacji scalania, o których wiesz, że są skomplikowane do wykonania: możesz scalać, zatwierdzać i testować w tej gałęzi zadań bez wprowadzania problemu dla głównej bieżącej gałęzi rozwoju)
• gałąź przejściowa: do przygotowania wydania, z niektórymi danymi lub plikami konfiguracyjnymi przedprodukcyjnymi.
• Oddziały prywatne, oddziały ad hoc i gałęzie rzadkie : w przypadku bardzo małych zadań, aby móc wykonać część pracy w toku bez czekania na formalne zakończenie lub przegląd testów.
  To pozwala „angażować się wcześnie, często”.

_{Inne interesujące koncepcje dotyczące VCS: Podstawowe pojęcia
(pierwotnie o ClearCase, ale również ważne dla dowolnego VCS)}

Wszystkie SCM XXI wieku mówią ci:

Oddział dla każdego zadania, nad którym pracujesz , bez względu na to, czy jest to nowa funkcja, naprawa błędu, test, cokolwiek. Nazywa się to gałęzią tematyczną i zmienia sposób pracy z SCM.

Dostajesz:

• Lepsza izolacja
• Lepsza identyfikowalność -> kojarzysz zadania z gałęziami, a nie z pojedynczymi zestawami zmian, dzięki czemu możesz zatwierdzać tyle razy, ile chcesz i nie narzuca limitu typu „jedno meldowanie na zadanie”.
• Zadania są niezależne (zwykle rozpoczynają się od stabilnej linii bazowej, więc skupiasz się tylko na kodzie, a nie na naprawianiu błędów od znajomych) i możesz wybrać, czy chcesz je zintegrować w pewnym momencie, czy później, ale zawsze są one poniżej kontrola wersji
• Możesz łatwo przejrzeć kod (z poziomu kontroli wersji, a nie przed zatwierdzeniem bzdur) przed przejściem do głównej linii

Narzędzia, które to potrafią:

• Git
• Bystry
• Plastikowy SCM

Narzędzia, które NIE MOGĄ tego zrobić:

• SVN
• CVS
• VSS
• TFS
• Z konieczności

Zależy to również od używanego narzędzia SCM. Nowoczesne SCM (git, mercurial itp.) Sprawiają, że tworzenie i niszczenie gałęzi w razie potrzeby jest coraz łatwiejsze. Pozwala to na przykład stworzyć jedną gałąź dla każdego błędu, nad którym pracujesz. Po połączeniu wyników z pniem odrzucasz gałąź.

Inne SCM, na przykład subversion i CVS, mają znacznie „cięższy” paradygmat rozgałęziania. Oznacza to, że gałąź jest uważana za odpowiednią tylko dla czegoś większego niż dwudziestoparametrowa łata. Tam gałęzie są klasycznie używane do śledzenia całych ścieżek rozwoju, takich jak poprzednia lub przyszła wersja produktu.

Gdy musisz wprowadzić znaczące i / lub eksperymentalne zmiany w bazie kodu, szczególnie jeśli chcesz wprowadzić zmiany pośrednie, bez wpływu na łącze trunk.

To zależy od typu używanego SCM.

W nowszych wersjach dystrybuowanych (takich jak git i mercurial) ciągle tworzysz gałęzie i tak czy inaczej. Często pracuję przez chwilę nad oddzielną gałęzią tylko dlatego, że ktoś zepsuł kompilację na głównej linii lub ponieważ sieć jest wyłączona, a następnie scalam zmiany z powrotem później, gdy zostanie naprawiony, i jest to tak łatwe, że nie jest to nawet irytujące .

Dokument (krótki i czytelny), który najbardziej pomógł mi zrozumieć, co dzieje się w systemach rozproszonych, to: UnderstandingMercurial .

W starszych systemach z centralnym repozytorium (takich jak CVS, SVN i ClearCase) jest to znacznie poważniejszy problem, który musi być rozstrzygnięty na poziomie zespołu, a odpowiedź powinna brzmieć bardziej jak `` utrzymanie starej wersji przy jednoczesnym umożliwieniu kontynuacja rozwoju na głównej linii ”lub„ jako część dużego eksperymentu ”.

Myślę, że model rozproszony jest znacznie lepszy i brakuje mu tylko ładnych narzędzi graficznych, aby stać się dominującym paradygmatem. Jednak nie jest to tak szeroko rozumiane, a koncepcje są różne, więc może być mylące dla nowych użytkowników.

Uważam, że rady Laury Wingerd i Christophera Seiwalda z Perforce są naprawdę zwięzłe i przydatne:

* Branch only when necessary.
* Don't copy when you mean to branch.
* Branch on incompatible policy.
* Branch late.
* Branch, instead of freeze.

Zobacz http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf, aby uzyskać szczegółowe wyjaśnienie każdego z nich i inne najlepsze praktyki.

Istnieją różne cele rozgałęziania:

1. Gałęzie funkcji / błędów. Dynamiczne i aktywne gałęzie, które są przenoszone z powrotem do pnia, gdy funkcja / naprawa błędu jest ukończona.
2. Gałęzie statyczne (tagi w Subversion, choć w istocie to tylko „normalna gałąź”). Zapewniają statyczny obraz, powiedzmy, uwolnienia. Chociaż można nad nimi pracować, pozostają nietknięte.

Może również wystąpić potrzeba rozgałęziania:

Kiedy tylko masz na to ochotę.

Prawdopodobnie nie będziesz często pracować ze scentralizowanym SCM, ponieważ gałęzie są częścią oficjalnego repozytorium, a to naprawdę nie wymaga wielu eksperymentów, nie wspominając o tym, że scalanie naprawdę boli.

OTOH, nie ma technicznej różnicy między oddziałem a kasą w rozproszonych SCM, a połączenia są dużo łatwiejsze. Będziesz mieć ochotę na rozgałęzianie się o wiele częściej.

Kiedy musisz wprowadzić zmiany w oparciu o aktualną gałąź, które nie są przeznaczone do następnego wydania z tej gałęzi (i nie wcześniej).

Na przykład zwykle pracujemy na pniu. Mniej więcej w momencie premiery ktoś będzie musiał wprowadzić zmianę, której nie chcemy w bieżącej wersji (może to być przed wydaniem, w tej chwili zwykle jest to po wydaniu). Jest to moment, w którym tworzymy gałąź, aby umieścić wydanie na własnej gałęzi i kontynuować rozwój następnego wydania na linii trunk.

Pomijając wszystkie szczegóły techniczne .....

Oddział, gdy wiesz, że łatwiej jest ponownie scalić!

Mając na uwadze, że scalanie zawsze będzie dokonywane wraz ze sposobem wykonywania pracy w projekcie.

Gdy to osiągnie, wszystkie inne trzeciorzędne kwestie wejdą do gry.