Před chvílí jsem dokoukal povídání Mika Masona a Martina Fowlera o dělání větví pro vlastnosti (feature branching). Do teď jsem si myslel, že to je dobrá věc, ale trochu mé přesvědčení zviklali.
O co jde? Některé týmy postupují tak, že pro každou novou vyvíjenou věc založí novou větev. Ta se začlení do hlavní vývojové větve, až když je daná věc hotová. Má to spoustu výhod a až dodnes mě nedošlo, že to s sebou nese i pár zásadních problémů. Pro nezkreslenou informaci se koukněte na to video, má jen jedenáct minut. Já tu shrnu jen to, co mi přišlo jako nejzásadnější.
Feature branching ohromně komplikuje refaktoring. Když si všimnete zatuchlého kódu, můžete ho refaktorovat, ale dost si tím zkomplikujete merge. Pokud totiž uděláte větší refaktoring, je velká šance, že se dotknete kódu, na kterém dělá někdo jiný. Dostanete se do situace, s kterou vám ani Git nepomůže. Strávíte pěkných pár chvilek ručním mergem a je tu pak dost velká pravděpodobnost, že příště si ten refaktoring dvakrát rozmyslíte. A to je špatně.
Když nad tím tak přemýšlím, potkalo mě to minulý týden. Udělal jsem ve své větvi refaktoring a začlenil jsem ho do hlavní větve. Kolega ale stále žil ve své větvi, mé geniální změny si proto nevšiml a svůj kód udělal o poznání hůře, než by mohl. Vůbec mě napadlo, že by to mohlo být způsobeno nějakou systematickou chybou.
Neříkám, že přestanu feature branching dělat, ale rozhodně se nad ním pořádně zamyslím.
Kolega by mel delat kazdy den rebase 🙂
Jeste me napadlo ze v ramci ticketu by se mozna nemely delat dve zmeny soucasne – asi bych vytvoril ticket/barnch na ten refactoring a nejdriv udelal ten a cherrypicknul do mastera a pak bych pokracoval na tom puvodnim branchi s implementaci te zmeny.
@ady Asi by to šlo. Ale je to přeci jen překážka, která mi ten refaktoring komplikuje. Nevím jestli je velká nebo malá, ale stojí mi v cestě. Dovedu si představit, že bych při představě toho, co všechno musím udělat nad vším jen mávl rukou a vykašlal se na to. A je celkem jedno, že by to zabralo třeba jen pár minut, už jen ten popis vypadá hrůzostrašně.
Myslím, že v rámci feature branch by se podle mě takový refaktoring dělat neměl. Je lepší udělat nejdřív refaktoring v masteru a pokud nemáš svoji feature branch pushnutou, tak si ji znovu rebasovat na základě toho commitu. Pokud už pushnutá je, tak holt merge nebo cherry pick do své feature branch.
A jinak myslím, že problém byl především na straně kolegy, který nesledoval změny, což by měl. V tomhle bylo výhodné svn. Tam to prostě bylo nejdřív update, pak commit.
Kdyz se nad tim zamyslim, tak mi pripada, ze michate dohromady veci, ktere spolu zas az tak nesouvisi. Konflikty vznikaji tehdy, kdy vice lidi saha do jednoho mista a jediny rozumny zpusob jak se jim vyhnout, je se proste dohodnout kdo kam bude vrtat. Je to nutna podminka a bez ni udelate konflikt po refactoringu bez ohledu na to, jestli pouzivate vetve nebo ne. Uplne staci, aby ten refactoring zabral par dni, ten druhy si po tu dobu nebude stahovat novinky a pak dostane balik, ktery mu to rozsype.
Na druhou stranu takovy refactoring sam o sobe muze byt bran jako feature – tedy by mel mit svou vetev, byt otestovan a kdyz jsou splneny QA, tak jit do masteru.
Cili ano, udelal jste systematickou chybu – nemluvite spolu o tom co delate (a pak navic hledate pricinu tam kde neni 🙂 ).
Obecne zadna metodika neni zazracna a vzdy je potreba u prace myslet a mluvit s ostatnimi a ne slepe nasledovat poucky.
Dík za zpětnou vazbu. Máte pravdu. Netvrdil jsem, že to nemá řešení, jenom je potřeba o tom problému vědět a myslet na něj. Jelikož jsem v Gitu nováček, nedošlo mi, že některé režimy používání spolu nesou i negativní důsledky.
Nesouhlasim ze s tim git nepomuze.
git rebase -i
A problematicky commit proste pri rebasu smazu. Hotovo.
Nedávno jsem na toto téma utrousil pár slov 🙂 http://rarous.net/weblog/404-prepinani-featur-a-vetveni-abstrakci.aspx
@Karell Konflikty můžou vzniknout pokud neintegrujete kontinuálně. Branching znemožňuje CI. Dále, refactoring nemůže trvat (z definice) dva dny. Pak jde o redesign.
@kukulich refactoring není věc na ticket. To je věc, která se má dělat průběžně, a feature branche by mu neměli stát v cestě.
@Ales – nejak mi neni jasne, proc sem vubec pletete CI. Zbezne jsem se podival na CI a podminky pro nasazeni, to je napr. v nasem pripade mimo realitu.
Nenasel jsem definici refactoringu, kde by byly zmineny ony 2 dny, i kdyby, tak mi pripada, ze je to jen akademicke slovickareni a tedy mi nedava smysl se o tom bavit. V realu se proste stava, ze nekdo meni veci vice nez dva dny a mezi tim je to nepouzitelne a tedy nezbyva, nez se dohodnout s ostatnimi kdo kam bude vrtat.
Tedy celkove nechapu vas prispevek v kontextu clanku o problematice vetveni a konfliktu.
@Karell – článek je v kontextu odkazovaného videa a tam se o feature branchingu mluví jako o překážce CI.
Refactoring je malá změna v kódu, která nemá vliv na jeho funkci, ale pouze na zlepšení jeho struktury. Každý refactoring se vejde pod minutu bez nástrojů, s nástroji v jednotkách sekund.
Doporučuji prostudovat knihy z podpisové řady Martina Fowlera jak o Refactoringu, tak o Continuous Integration. Jistě vám pomohou pochopit mé příspěkny a vnesou vás do kontextu.
Tady nejde o akademické slovíčkaření. Názvy a jejich definice jsou tu od toho, aby si lidé rozuměli, když o něčem hovoří. Nazývat redesign několika denním refactoringem, jen proto, že to slovo je teď cool a neděsí tolik manažery je velmi nešťastné.
ještě dodatek (omlouvám se za spamování). CI jsem tam zapletl ještě proto, že tu píšete o vzniku konfliktů. CI je praktikou, která v praxi výskyt konfliktů velmi snižuje.
@Ales – ok, uz se orientuju…
S tou terminologii to asi nebude tak jednoduche, neslysel jsem ve svem okoli nikoho pouzivat termin redesign a refactoringem se vetsinou mysli netrivialni prekopani kodu bez ohledu na casovou narocnost, to je proste realita. U nas napr. mame refactoring projekty trvajici nekolik mesicu, to uz asi tezko nekdo zmeni (coz neznamena, ze vam beru definice, taky uznavam, ze jsou potrebne… 🙂 )
Neco jako CI se mi samotnemu libi, u malych projektu nevidim problem, ale zajimalo by me, jestli si nekdo mysli, ze je to mozne nasadit i na vetsi projekty. Pro predstavu – 50 vyvojaru, build trva 2-3 hodiny, testy 10h. Muzete to treba napsat do toho pojednani o CI co chystate.
Tady je další názor http://continuousdelivery.com/2011/07/on-dvcs-continuous-integration-and-feature-branches/