The ZeoTech Series: Git Workflow: Rebase vs Merge

Ég gekk til liðs við fyrirtækið á síðasta ári í apríl í teymi gagnaverkfræðinga. Liðið samanstóð af 3 nemendum og 3 gagnaverkfræðingum í samvinnu við útgáfustýringarkerfið, Git. Við höfðum ekki mikið af skipulagi til að ritrýna kóðann sem fór í framleiðslu. Við notuðum togbeiðnir á Github á sínum tíma, en við höfðum öll málin í gitgeymslunum okkar sem byrjunarliðið gæti haft. Við bættum óhefðbundnum skrám inn í geymslurnar (svo sem .DS_Store) ásamt harðkóðuðum slóðum í staðbundnar skrár, engin almennileg framsalsskilaboð, engin rökrétt skuldbinding svo eitthvað sé nefnt.

Síðan þá erum við komin langt. Lið okkar hefur vaxið úr 6 verkfræðingum í 14 verkfræðinga. Við höfum gert umtalsverðar endurbætur á kóðaúttektarferli okkar. Við tryggjum að að minnsta kosti tveir verkfræðingar sjái hvert stykki af kóða áður en það fer í framleiðslu. Git-skuldbindingarnar okkar eru miklu rökréttari og fylgja alltaf miklu meira og ítarlegri framboðsskilaboð en áður. Í gegnum allt þetta var ein af ákvörðunum sem við þurftum að taka, að velja rétt Git Workflow, sérstaklega hvort að „sameina“ draga beiðnir eða nota „rebase and sameining“ í staðinn.

Í þessari grein fjalla ég fyrst um „endurröðun“ verkflæðisins sem við fylgjumst með á Zeotap í teyminu Data Engineering. Þá vil ég halda því fram að „endurröðun“ verkflæðið byggi upp betri gangvirkni liðsins samanborið við „flæðið“ vinnuflæðið. Þrátt fyrir að erfiðara sé að fylgja „endurröðun“ verkflokksins hefur það fjölmarga kosti. Til dæmis neyðir það verktaki til að gera rökrétt skuldbindingar sem leiða til betri læsileika fyrir kóða og eignarhald á kóða. Það fellur líka vel að lipurri stefnumótun hugbúnaðarþróunar með því að tryggja tíðar skuldbindingar og draga beiðnir.

Ákvörðunin

Á zeotap vinnur hver verktaki að tilteknum hluta / eiginleikum verkefnis, byggir skuldbindingar í eigin útibúi. Þegar rökréttur hluti af aðgerðinni er lokið, vekur framkvæmdaraðilinn fram beiðni um draga á Github. Þá fara að minnsta kosti tveir ólíkir jafningjafræðingar yfir þessa togsbeiðni áður en hægt er að sameina hana í húsbónda- / sprettigreinina.

[Tilvísun: https://blog.github.com/2016-09-26-rebase-and-merge-pull-requests/]

Við teljum tvo valkosti saman um að draga beiðnina saman. Við getum annað hvort „sameinað“ togarbeiðnina sem leiðir til sameiningar skuldbinda, sem er sérstök tegund af skuldbindingum sem sameina þróunarútibú í aðal / sprint útibú [https://www.atlassian.com/git/tutorials/merging-vs -breiðsla]. Röð sameiningar skuldbindur í Git geymslu byggir flókið tré skuldbindinga sem leiðir til núverandi útgáfu af kóðanum.

[Tilvísun: https://www.atlassian.com/git/tutorials/merging-vs-rebasing]

Annar kostur er að „endurfella“ allar skuldbindingar í útibú fyrir þróunaraðila ofan á master / sprint útibúinu og sameina dráttarbeiðnina með því að nota hraðvirka sameiningarstefnu. [https://ariya.io/2013/09/fast-forward-git-merge]. Þetta skilar sér í uppbyggingu þar sem það lítur út fyrir að allar skuldbindingarnar hafi verið gerðar beint á húsbónda- / sprettibúsgreinina og útibúsgreinin hafi aldrei raunverulega verið til. Í reynd eyðum við reyndar útibúinu þegar verktakafyrirspurnin hefur verið sameinuð.

[Tilvísun: https://www.atlassian.com/git/tutorials/merging-vs-rebasing]

Endurtaktu verkflæði við Zeotap

Áður en við berum saman bæði verkflæðin, hér að neðan er „endurröðun“ vinnuflæðisins sem við fylgjum á zeotap. Í þessu verkflæði neyðum við okkur aldrei til að uppfæra meistara- / sprettigreinina þar sem aðeins verktaki getur þvingað uppfærslu útibúsins.

Upphlaða vs sameina

Nú skulum við bera saman verkflæði „sameina“ og „endurfæða“.

Endurreisn er hörð

Í fyrsta lagi skal ég sætta mig við að „endurröðun“ er flókin, eyðileggjandi og tekur tíma að venjast. Ef átök eru, þarf að leysa þau fyrir hverja skuldbindingu sem er endurflutt á núverandi útibú. Þegar „endurskipulagningu“ er lokið þarf maður að eyðileggja ýta til afskekktu greinarinnar með óheiðarlegum hætti sem leiðir ekki af sér örugga framkvæmd. Github hefur aðferðir til að tryggja að sprettinum / aðalútibúinu sé aldrei breytt þegar það hefur verið framið, engu að síður er ferlið flókið.

Aftur á móti er „tiltölulega auðveldara að„ sameina “, þarfnast lítillar fyrirhafnar og git vinnur mest af verkinu fyrir þig. Það skapar „sameina“ skuldbindingu sem beinlínis merkir sameiningu framkvæmdarútibúsins í sprett / aðalútibúið. Þetta getur líka leitt til átaka, en þau eru leyst í einu skrefi fyrir öll skuldbindingar í útibúum ólíkt „endurröðun“ nálguninni.

Rökrétt skuldbindingar

Þó að „endurröðun“ sé hörð og eyðileggjandi styrkir það hugmyndina um rökrétt skuldbindingar. Með rökréttum skuldbindingum, þá meina ég að hver skuldbinding hefur fullkomna rökrétta einingar af kóða svo sem að laga villu, bæta við eiginleikum eða hluta af henni. Þetta hefur virkilega hjálpað okkur að bæta læsileika skuldbindinga okkar í git geymslu. Þegar verktaki þarf að endurbæta útibú sitt í master / sprint greininni er röð nýrra skuldbindinga á útibú framkvæmdaraðila notuð ofan á master / sprint branch. Ef þessi skuldbinding er ekki rökrétt gæti verið leiðinlegt að leysa ágreining í þessu ferli. Rökrétt skuldbindingar gera okkur kleift að greina með skýrum hætti hvernig eigi að leysa ágreininginn út frá rökréttri breytingu sem hefur verið gerð á tilteknu skuldbindingum. Þetta styrkir hugmyndina um að byggja upp rökrétt skuldbindingar meðan þú skrifar kóða. Þvert á móti, þegar um er að ræða „sameiningar“ vinnuflæðis, þarf að leysa ágreininginn í „sameina“ skuldbindingunni og engin slík þörf á að búa til rökrétt skuldbindingar myndast nokkru sinni.

Ábyrgð / eignarhald framkvæmdaraðila

Þegar git er ófær um að framkvæma „sameiningu“ vegna átaka í kóðanum upplýsir það framkvæmdaraðila venjulega og hann verður að taka málið í sínar hendur. Ef um er að ræða „endurröðun“ verkflæðis er þetta gert á meðan dregið er frá beiðni um tog. Þegar um er að ræða „flæði“ vinnuflæði eru stundum átökin leyst á meðan sameiningin dregur saman. Það sem okkur líkaði mjög við „endurröðun“ vinnuflæðisins er að það tekur frá valinu um sameiningu síðar. Það verður á ábyrgð framkvæmdaraðila að sjá til þess að allar breytingar fari fram á réttan hátt áður en beiðni um tog er sameinuð. Framkvæmdaraðilinn ber ábyrgð á að endurbæta breytingar sínar á húsbónda / sprettibúnaðinum áður en hann býr til togbeiðni í samanburði við að treysta á Git eða kóða gagnrýnendur til að sameina breytingarnar á togarbeiðninni.

Skuldbinda sögu og endurtaka skuldbindingar

Þetta er einföld afleiðing þess að nota „endurröðun“ vinnuflæðisins. Það veitir línulega sögu um skuldbindingar í geymslu sem auðvelt er að rökræða um. Einnig frá sögu er auðveldara að skilja hvernig núverandi stöðu kóðans er náð. Það er líka miklu auðveldara að afturkalla skuldbindingar úr línulegri sögu skuldbindinga. Með „sameining“ skuldbindingunni er byggð upp mun flóknari trjábygging skuldbindinga sem gerir það erfitt að bera kennsl á og snúa aftur.

[Tilvísun: https://www.atlassian.com/git/tutorials/undoing-changes/git-revert]

Lipur heimur

Þetta er lokakosturinn sem ég vildi ræða í þessari grein. Ég tel að „endurröðun“ nálgunin passi betur inn í heim lipurrar hugbúnaðarþróunar. Umhverfi Zeotap er afar hraðskreytt og kröfur og kóða hafa tilhneigingu til að breytast mjög oft. Í svo hröðu umhverfi hjálpar „endurröðun“ verkflæðið okkur að fylgjast með kóðabreytingum sem gerðar eru af jafningjahönnuðum. Við búum til og sameinum kóða okkar oft með beiðnum um að draga til að tryggja að útibú okkar standi ekki eftir húsbóndanum / sprettinum. Í ljósi þess að „endurröðun“ krefst lausnar ágreininga sem framin eru með skuldbindingum vegna allra skuldbindinga í beiðninni um að draga, því færri sem fremja, því auðveldara verður að leysa ágreining. Það hvetur því verktaki til að sameina breytingar eins oft og mögulegt er til að draga úr viðleitni við lausn ágreininga. Stundum þegar við finnum til átaka, tökum við líka saman við okkur til að skilja ástæðuna að baki. Þetta leiðir okkur alltaf til að verða miklu meira samstarfsteymi.

Niðurstaða

„Rebase“ og „Merge“ nálgunin eru bæði ágætar aðferðir fyrir Git vinnuflæðið sem hægt er að nota á vinnustaðnum. Engu að síður held ég að meginmunurinn sé sá að „endurflæði“ vinnuflæðisins er eyðileggjandi og tekur nokkurn tíma að venjast því að „sameina“ vinnuflæðið er auðveldara í notkun og þarfnast ekki þjálfunar. Þrátt fyrir það hefur „endurröðun“ verkflæðið smá forskot á „að sameinast“ í lipuru umhverfi: það krefst þess að verktaki hugsi dýpra um skuldbindingar sínar til að byggja upp rökrétt skuldbindingar og taka eignarhald á hverri beiðni um að draga, sem gefur línulega sögu sem er auðvelt að rökræða um.

Við höfum notað „endurröðun“ verkflæðið í meira en eitt ár núna. Í hvert skipti sem verktaki tekur þátt í teyminu hjálpum við þeim um borð með Git vinnuflæðinu okkar. Þegar þeir hafa vanist þessu vinnuflæði fylgja restin af kostunum einfaldlega.

Um höfundinn

Aman Mangal, hugbúnaðarverkfræðingur hjá zeotap, er einn af mörgum liðsmönnum sem vinnur með gríðarlegt magn af gögnum daglega. Helstu verkefni hans fela í sér að stjórna gögnum neyslu mismunandi félaga í kerfum zeotap ásamt því að fylgjast með og hámarka gagnaleiðsluna til að hægt sé að virka. Eftir að hafa lokið tölvunarfræðinámi bæði á Indlandi og í Bandaríkjunum hafði Aman tækifæri til að leggja sitt af mörkum til fyrirtækja eins og Nokia Bell Labs, Zerostack og Lumiata áður en hann gekk til liðs við Zeotap. Meðal sérsviðs hans eru meðal annars gagnagerð, dreifð kerfi og linux ílát.

Frekari upplýsingar um prófíl Amans er að finna á Linkedin síðu sinni hér.