Odpowiedzi:
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ć:
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:
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:
Narzędzia, które to potrafią:
Narzędzia, które NIE MOGĄ tego zrobić:
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:
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.