Po co branchuję?

Ludzie branche tworzą…

Motywów do tworzenia gałęzi w projektach jest co nie miara. W nie tak prehistorycznych czasach (które chyba z resztą trwają do dziś) królowania CVS, a później SVN większość rzeczy trafiała bezpośrednio do trunka – głównej gałęzi. Rozgałęzienia były tworzone w momentach, gdy projekt rzeczywiście obierał dwa, dosyć odmienne biegi rozwoju (np. v1 i v2 – obie rozwijane). Inną strategią (nie wykluczającą pierwszej!) było tworzenie gałęzi – stabilnej, rozwojowej, a czasem eksperymentalnej i odpowiednie „code promotion”, czyli „przenoszenie” kodu między gałęziami: stabilna <- rozwojowa <- eksperymentalna. Jeszcze inny sposób wykorzystywania gałęzi, to oddzielny branch dla każdego podzespołu. Tak stworzone gałęzie były stopniowo (zwykle po zakończeniu pracy nad modułem) włączane do wspomnianego trunka. Powodem stosunkowo niedużej liczby rozgałęzień była największa bolączka wspomnianych scentralizowanych systemów kontroli wersji – nieprzyjemny merge.

W nowoczesnych-trendy-lux-czasach rozproszonych systemów kontroli wersji takich jak git, hg, bzr promuje się podejście „branch-per-feature” – czyli tworzenie nowej gałęzi dla każdego, nowego „ficzera”, każdego naprawianego buga itd. Nic co jest „work-in-progress” nie powinno trafić do gałęzi głównej. Wszystko to jest możliwe dzięki mniej bolesnemu merge’owaniu gałęzi, a takie podejście jest samo w sobie niezwykle wygodne i efektywne.

Nieco kreatywności

Przy okazji serii postów którą tworzę, potrzebowałem prostego i efektywnego sposobu udostępniania kodów dla poszczególnych odcinków serii. W grę wchodziło uploadowanie paczek z aktualnym kodem, dla danego odcinka, na serwer i linkowanie ich w notce. Szczerze powiedziawszy – nie znoszę takiego podejścia. Wydaje mi się, że łatwo doprowadza to do bałaganu, nieaktualnych wersji i niedziałających linków. Potrzebowałem lepszego sposobu i do głowy przyszedł mi pomysł.. aby każdy odcinek serii był oddzielnym branchem. Takie rozwiązanie ma szereg zalet: Czytelnicy mogą z łatwością pobrać aktualny, dla danego odcinka, kod; mogę bezproblemowo wnosić zmiany do kodu dla konkretnej części; struktura tego podejścia jest bardzo przejrzysta, a ponadto wyjątkowo łatwo się tym wszystkim zarządza. Z dodatkowych zalet warto wspomnieć o przeglądarce kodu na githubie, która umożliwia Czytelnikom natychmiastowy podgląd kodu dla danej części, bez potrzeby ściągania go. Jak dla mnie – rewelacja :) Przedstawione przeze mnie podejście ma oczywiście sens tylko w serii postów ze stopniowo przyrastającym kodem. Puryści mogliby jednak powiedzieć, że takie rzeczy powinno załatwiać się labelami, ale jak już wspomniałem – mam zamiar w miarę potrzeb aktualizować kod dla konkretnych odcinków, a zarządzanie etykietami, to nic przyjemnego.

Nowa, lepsza przyszłość? ;)

Cieszy mnie, że era linkowania paczek z kodem dobiega końca, a repozytoria wchodzą w coraz to nowe obszary działalności – ludzie za pomocą systemów kontroli wersji rozpowszechniają najróżniejsze rzeczy – począwszy od configów, aż do dokumentów. Niewątpliwa w tym zasługa ogólnodostępnych, darmowych, świetnie przygotowanych serwisów takich jak github, gitorious, czy bitbucket. Wydaje mi się, że używanie systemów kontroli wersji jest po prostu efektywne, łatwe, szybkie i pewne, zatem ich (nadchodząca) wszechobecność jest rzeczą naturalną. Koniec broken linków! :)