Pagtutulungan nang walang kalituhan: pag-unawa sa mga diskarte sa pagsasanga sa Git

Panimula

Ang Git ay naging de facto na pamantayan ng industriya para sa mga version control system sa software development. Dapat mo munang basahin ang aking artikulo tungkol sa kung ano ang Git at kung paano magsimula. Nabasa mo na ba? Magaling, sige na! Gusto man o hindi, ang tool na ito na nilikha ni Linus Tovalds ay hindi magreretiro. Kaya, makatuwirang pag-usapan kung paano gumagana ang mga distributed team sa Git at kung anong diskarte sa pagsasanga ang dapat nilang piliin para dito. Ito ay hindi isang inconsequential na tanong. Kapag nag-assemble ng bagong development team na hindi nagtutulungan dati, ang diskarte sa pagsasanga ay kadalasang isa sa mga unang bagay na dapat pagdesisyunan. At ang ilang mga tao ay bumubula ang bibig upang patunayan na ang isang diskarte ay mas mahusay kaysa sa iba. Kaya, nais kong ihatid sa iyo ang ilang pangkalahatang impormasyon tungkol sa kanila.

Kailangan ba ang mga diskarte sa pagsasanga?

Kailangan talaga sila. Napakakailangan. Dahil kung ang koponan ay hindi sumang-ayon sa isang bagay, ang bawat miyembro ng koponan ay gagawin kung ano ang gusto niya:

• nagtatrabaho sa kahit anong branch
• pagsasama sa arbitrary na iba pang mga sangay
• pagtanggal ng ilang sangay
• paglikha ng mga bago
• at sa gayon ang bawat miyembro ng koponan ay kikilos sa isang hindi pinamamahalaang daloy.

Iyon ang dahilan kung bakit mayroon kaming tatlong diskarte na isasaalang-alang sa ibaba. Tara na!

Daloy ng GitHub

Ang diskarteng sumasanga na ito, kakaiba, ay mas gusto sa GitHub :) Ito ay may kasamang hanay ng mga panuntunan :

1. Ang code sa master branch ay hindi dapat sirain. Dapat ay handa itong i-deploy anumang oras. Iyon ay, hindi ka dapat maglagay ng code doon na pumipigil sa iyo sa pagbuo ng proyekto at pag-deploy nito sa server.
2. Kapag nagpaplano kang gumawa ng bagong functionality, kailangan mong gumawa ng bagong feature branch batay sa master branch at bigyan ito ng makabuluhang pangalan. I-commit ang iyong code nang lokal at regular na itulak ang iyong mga pagbabago sa parehong sangay sa remote repository.
3. Magbukas ng pull request (maaari mong basahin ang tungkol sa pull request dito ) kapag sa tingin mo ay handa na ang trabaho at maaaring isama sa master branch (o kung hindi ka sigurado, ngunit gusto mong makakuha ng feedback sa gawaing ginawa).
4. Pagkatapos maaprubahan ang bagong feature sa pull request, maaari itong isama sa master branch.
5. Kapag ang mga pagbabago ay pinagsama sa master branch, dapat itong i-deploy kaagad sa server.

Ayon sa GitHub Flow, bago ka magsimulang gumawa ng bago, ito man ay isang pag-aayos o isang bagong feature, kailangan mong lumikha ng bagong sangay batay sa master at bigyan ito ng angkop na pangalan. Susunod, magsisimula ang trabaho sa pagpapatupad. Dapat kang palaging magsumite ng mga commit sa malayong server na may parehong pangalan. Kapag napagpasyahan mo na handa na ang lahat, kailangan mong lumikha ng kahilingan sa paghila sa master branch. Pagkatapos, kahit isa, o mas mabuti pa, dapat tingnan ng dalawang tao ang code na ito bago i-click ang "Aprubahan." Karaniwan, ang pinuno ng koponan ng proyekto at isang pangalawang tao ay dapat talagang tumingin. Pagkatapos ay maaari mong kumpletuhin ang kahilingan sa paghila. Ang GitHub Flow ay kilala rin sa paghimok ng tuluy-tuloy na paghahatid (CD) sa mga proyekto. Ito ay dahil kapag ang mga pagbabago ay napupunta sa master branch, dapat itong i-deploy kaagad sa server.

GitFlow

Ang nakaraang diskarte (GitHub Flow) ay hindi masyadong kumplikado sa core nito. Mayroong dalawang uri ng sangay: master at tampok na sangay. Ngunit ang GitFlow ay mas seryoso. Hindi bababa sa, ang larawan sa itaas ay dapat gumawa na malinaw :) Kaya paano gumagana ang diskarte na ito? Sa pangkalahatan, ang GitFlow ay binubuo ng dalawang paulit-ulit na sangay at ilang uri ng pansamantalang sangay. Sa konteksto ng GitHub Flow, ang master branch ay nagpapatuloy at ang iba ay pansamantala. Patuloy na mga sanga

• master: Walang dapat hawakan o itulak ang anuman sa sangay na ito. Sa diskarteng ito, kinakatawan ng master ang pinakabagong stable na bersyon, na ginagamit sa produksyon (iyon ay, sa isang tunay na server)
• pag-unlad: Ang sangay ng pag-unlad. Ito ay maaaring hindi matatag.

Nangyayari ang pag-unlad gamit ang tatlong pantulong na pansamantalang sangay :

1. Mga tampok na sangay — para sa pagbuo ng bagong functionality.
2. Mga sanga ng paglabas — para sa paghahanda para sa pagpapalabas ng bagong bersyon ng proyekto.
3. Mga sanga ng hotfix — para sa mabilis na pag-aayos ng bug na natagpuan ng mga totoong user sa isang tunay na server.

Tampok na mga sangay

Ang mga feature na branch ay nilikha ng mga developer para sa bagong functionality. Dapat silang palaging nilikha batay sa sangay ng pag-unlad. Pagkatapos makumpleto ang trabaho sa bagong functionality, kailangan mong gumawa ng pull request sa development branch. Maliwanag, ang malalaking koponan ay maaaring magkaroon ng higit sa isang sangay ng tampok sa isang pagkakataon. Tingnan muli ang larawan sa simula ng paglalarawan ng diskarte sa GitFlow.

Ilabas ang mga sangay

Kapag handa na ang kinakailangang hanay ng mga bagong feature sa sangay ng pagpapaunlad, maaari kang maghanda para sa pagpapalabas ng bagong bersyon ng produkto. Ang isang release branch, na ginawa batay sa development branch, ay makakatulong sa amin dito. Kapag nagtatrabaho sa release branch, kailangan mong hanapin at ayusin ang lahat ng mga bug. Anumang mga bagong pagbabago na kinakailangan upang patatagin ang release branch ay dapat ding i-merge pabalik sa development branch. Ginagawa ito upang maging matatag din ang sangay ng pag-unlad. Kapag sinabi ng mga tester na ang branch ay sapat na stable para sa isang bagong release, ito ay pinagsama sa master branch. Mamaya isang tag, na nakatalaga ng numero ng bersyon, ay ginawa para sa commit na ito. Upang makakita ng halimbawa, tingnan ang larawan sa simula ng diskarte. Doon mo makikita ang Tag 1.0— isa lang itong tag na nagsasaad ng bersyon 1.0 ng proyekto. At sa wakas, mayroon kaming sangay ng hotfix.

Mga sanga ng hotfix

Ang mga sanga ng hotfix ay inilaan din para sa pagpapalabas ng bagong bersyon sa master branch. Ang pagkakaiba lang ay hindi planado ang mga release na iyon. May mga sitwasyon kung kailan nakapasok ang mga bug sa inilabas na bersyon at natuklasan sa kapaligiran ng produksyon. Kunin ang iOS: sa sandaling mailabas ang isang bagong bersyon, agad kang makakakuha ng isang grupo ng mga update na may mga pag-aayos para sa mga bug na natagpuan pagkatapos ng paglabas. Alinsunod dito, kailangan nating mabilis na ayusin ang isang bug at maglabas ng bagong bersyon. Sa aming larawan, ito ay tumutugma sa bersyon 1.0.1. Ang ideya ay ang pagtatrabaho sa bagong functionality ay hindi kailangang huminto kapag kinakailangan upang ayusin ang isang bug sa isang tunay na server (o gaya ng sinasabi natin, "in prod" o "in production"). Dapat gawin ang hotfix branch mula sa master branch, dahil kinakatawan nito kung ano ang kasalukuyang tumatakbo sa produksyon. Sa sandaling handa na ang pag-aayos ng bug, ito ay pinagsama sa master, at isang bagong tag ay nilikha. Tulad ng paghahanda ng isang release na branch, dapat ding pagsamahin ng isang hotfix branch ang pag-aayos nito pabalik sa development branch.

Forking workflow

Sa forking workflow, ang pag-unlad ay nagsasangkot ng dalawang repositoryo:

1. Ang orihinal na repositoryo, kung saan isasama ang lahat ng pagbabago.
2. Isang imbakan ng tinidor. Ito ay isang kopya ng orihinal na repositoryo, na pagmamay-ari ng isa pang developer na gustong gumawa ng mga pagbabago sa orihinal.

Mukhang medyo kakaiba sa ngayon, tama ba? Ang sinumang nakatagpo na ng open-source development ay pamilyar na sa diskarteng ito. Ibinibigay ng diskarteng ito ang sumusunod na kalamangan: maaaring mangyari ang development sa isang fork repository nang hindi nagbibigay ng mga pahintulot para sa joint development sa orihinal na branch. Naturally, ang may-ari ng orihinal na repository ay may karapatang tanggihan ang mga iminungkahing pagbabago. O upang tanggapin at pagsamahin ang mga ito. Maginhawa ito para sa may-ari ng orihinal na repositoryo at sa developer na gustong tumulong sa paggawa ng produkto. Halimbawa, maaari kang magmungkahi ng mga pagbabago sa Linux kernel . Kung magpasya si Linus na may katuturan sila, idadagdag ang mga pagbabago (!!!).

Isang halimbawa ng forking workflow

Ang forking workflow ay inilalapat sa GitHub kapag mayroong library na gusto mong gamitin. Mayroon itong bug na pumipigil sa iyo na gamitin ito nang buo. Ipagpalagay na sumisid ka nang malalim sa problema at alam mo ang solusyon. Gamit ang forking workflow, maaari mong ayusin ang problema nang walang karapatang magtrabaho sa orihinal na repositoryo ng library. Upang makapagsimula, kailangan mong pumili ng ilang repositoryo, halimbawa, ang Spring Framework . Hanapin at i-click ang button na "Fork" sa kanang sulok sa itaas: Magtatagal ito. Pagkatapos ay lilitaw ang isang kopya ng orihinal na repositoryo sa iyong personal na account, na magsasaad na ito ay isang tinidor:Ngayon ay maaari ka nang magtrabaho sa repositoryong ito gaya ng dati, pagdaragdag ng mga pagbabago sa master branch, at kapag handa na ang lahat, maaari kang gumawa ng pull request sa orihinal na repository. Upang gawin ito, i-click ang pindutan ng Bagong kahilingan sa paghila :

Aling diskarte ang pipiliin

Ang Git ay isang flexible at makapangyarihang tool na hinahayaan kang magtrabaho gamit ang iba't ibang uri ng mga proseso at diskarte. Ngunit kung mas maraming pagpipilian ang mayroon ka, mas mahirap na magpasya kung aling diskarte ang pipiliin. Malinaw na walang iisang sagot para sa lahat. Ang lahat ay nakasalalay sa sitwasyon. Sabi nga, may ilang mga alituntunin na makakatulong dito:

1. Pinakamabuting piliin muna ang pinakasimpleng diskarte. Lumipat sa mas kumplikadong mga diskarte lamang kapag kinakailangan.
2. Isaalang-alang ang mga diskarte na may kakaunting uri ng sangay hangga't maaari para sa mga developer.
3. Tingnan ang mga kalamangan at kahinaan ng iba't ibang mga diskarte, at pagkatapos ay piliin ang kailangan mo para sa iyong proyekto.

Iyon lang ang gusto kong sabihin tungkol sa mga diskarte sa pagsasanga sa Git. Salamat sa iyong pansin :) Sundan ako sa GitHub , kung saan madalas kong ipo-post ang aking mga likha na kinasasangkutan ng iba't ibang teknolohiya at tool na ginagamit ko sa aking trabaho.