Pagtutulungan ng magkakasama nang walang Pagkalito: Pag-unawa sa Mga Istratehiya sa Pagsanga sa Git

Panimula

Ang Git ay naging de facto na pamantayan ng industriya para sa kontrol ng bersyon sa paglikha ng software. Upang malaman kung ano ang git at kung paano magsimula, basahin muna ang aking artikulo tungkol dito. Nabasa mo na ba? Mahusay, magpatuloy tayo! Gustuhin man o hindi, ang instrumento na nilikha ni Linus Towalds ay hindi magreretiro. Samakatuwid, makatuwirang pag-usapan kung paano gumagana ang mga ipinamahagi na koponan sa git at kung anong diskarte sa pagsasanga ang pipiliin para dito. At ito ay hindi isang idle na tanong sa lahat. Kadalasan, sa isang sitwasyon kung saan ang isang bagong pangkat ng mga developer na hindi nakikipagtulungan sa isa't isa ay binuo, ang diskarte sa pagsasanga ay isa sa mga unang bagay na kailangang magpasya. At may mga taong bubula ang bibig para patunayan na ang isang diskarte ay mas mahusay kaysa sa iba. Samakatuwid, nais kong ihatid sa iyo ang impormasyon tungkol sa kung ano sila sa pangkalahatan.

Kailangan ba ang mga diskarte sa pagsasanga?

Ngunit kailangan sila, at kailangan pa rin sila. Dahil kung hindi ka sumang-ayon sa isang bagay sa koponan, lumalabas na gagawin ng lahat ang gusto nila:

• magtrabaho sa sangay na gusto niya;
• sumanib sa ibang sangay na gusto niya;
• tanggalin ang ilang mga sangay;
• lumikha ng mga bago;
• at iba pa—bawat isa sa mga miyembro ng koponan ay nasa isang hindi nakokontrol na daloy.

Samakatuwid, nasa ibaba ang tatlong estratehiya. Go!

Diskarte sa Daloy ng GitHub

Ang diskarte sa pagsasanga, gaano man ito kakaiba, ay mas gusto sa GitHub :) Kalakip nito ay isang hanay ng mga panuntunan na kailangang sundin:

1. Ang code sa master branch ay dapat na walang putol at handa na i-deploy anumang oras (iyon ay, hindi ka maaaring maglagay ng code doon na hahadlang sa iyong pagbuo ng proyekto at pag-deploy nito sa server).
2. Kapag nagpaplano kang gumawa ng bagong functionality, kailangan mong lumikha ng bagong branch (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 isang remote na imbakan.
3. Magbukas ng Pull-Request (mababasa mo kung ano ang pull-request dito ) kapag may malinaw na pakiramdam na handa na ang trabaho at maaaring isama sa master branch (o kung hindi ka sigurado, ngunit gusto mong makakuha ng feedback sa ang gawaing ginawa).
4. Pagkatapos maaprubahan ang isang bagong feature sa isang pull request, maaari itong isama sa master branch.
5. Kapag ang mga pagbabago ay pinagsama sa master branch, kailangan nilang i-deploy kaagad sa server.

Ayon sa GitHub Flow, lumalabas na bago ka magsimulang gumawa ng bago, maging ito ay isang pag-aayos o isang bagong tampok, kailangan mong lumikha ng isang bagong sangay batay sa master at bigyan ito ng angkop na pangalan. Susunod, magsisimula ang trabaho sa pagpapatupad. Kailangan mong patuloy na itulak ang mga commit sa isang malayong server na may parehong pangalan. Kapag naiintindihan mo na ang lahat ay handa na, kailangan mong lumikha ng isang kahilingan sa paghila sa master branch. Pagkatapos, kahit isa, o mas mabuti pa, dapat tingnan ng dalawang tao ang code na ito at i-click ang Approve. Karaniwan, dapat tingnan ito ng pinuno ng koponan ng proyekto at ng ibang tao, at pagkatapos ay maaari mong kumpletuhin ang kahilingan sa paghila. Ang GitHub Flow ay kilala rin sa pagmamaneho ng Continuous Delivery (CD) sa isang proyekto. Dahil kapag ginawa ang mga pagbabago sa master branch, dapat na agad itong i-deploy sa server.

Diskarte sa GitFlow

Ang nakaraang diskarte (GitHub Flow) ay mahalagang hindi masyadong kumplikado. Mayroong dalawang uri ng sangay: master at tampok na sangay. Ngunit ang GitFlow ay mas seryoso. Hindi bababa sa naiintindihan mo ito mula sa larawan sa itaas) Kaya, paano gumagana ang diskarteng ito? Sa pangkalahatan, ang GitFlow ay binubuo ng dalawang permanenteng sangay at ilang uri ng pansamantalang sangay (Sa konteksto ng GitHub Flow, ang master branch ay permanente at ang iba ay pansamantala). Mga permanenteng sangay:

• master: walang dapat hawakan ang sangay na ito o itulak ang anumang bagay doon. Sa diskarteng ito, ipinapakita ng master ang pinakabagong stable na bersyon na ginagamit sa produksyon (iyon ay, sa totoong server);
• ang kaunlaran ay sangay para sa kaunlaran. Ito ay maaaring maging hindi matatag.

Ang pag-unlad ay isinasagawa gamit ang tatlong pantulong na pansamantalang sangay :

1. Mga sangay ng tampok - para sa pagbuo ng bagong pag-andar.
2. Mga sangay ng paglabas - upang maghanda para sa pagpapalabas ng isang bagong bersyon ng proyekto.
3. Ang mga sanga ng hotfix ay isang mabilis na solusyon sa isang depekto na natagpuan na 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 nakabatay sa sangay ng pag-unlad. Pagkatapos makumpleto ang trabaho sa bagong functionality, kailangan mong gumawa ng pull request sa development branch. Malinaw na sa malalaking koponan ay maaaring magkaroon ng higit sa isang sangay ng tampok sa isang pagkakataon. Muli, bigyang pansin ang larawan sa simula ng paglalarawan ng diskarte sa GitFlow.

Ilabas ang mga sangay

Kapag ang kinakailangang bilang ng mga bagong feature ay inihanda sa development branch, maaari kang maghanda na maglabas ng bagong bersyon ng produkto. Tutulungan tayo ng sangay ng pagpapalabas dito. na nilikha batay sa sangay ng pag-unlad. Habang nagtatrabaho sa release branch, kailangan mong hanapin at ayusin ang lahat ng mga depekto. Anumang mga bagong pagbabago na kinakailangan upang patatagin ang release branch ay dapat ding i-merge pabalik sa development. Ginagawa ito upang maging matatag at mapaunlad ang sangay. Kapag sinabi ng mga tagasubok na ang branch ay sapat na stable para sa isang bagong release, ito ay pinagsama sa master branch. Susunod, isang tag ang ginawa sa commit na ito (tag: maaari mong basahin ang higit pa tungkol dito ) , na nakatalaga ng numero ng bersyon. Bilang halimbawa, maaari mong tingnan ang larawan sa simula ng diskarte. Kaya, mayroong Tag 1.0 ay isang label lamang na nagpapahiwatig ng bersyon 1.0 ng proyekto. At ang huling bagay ay isang hotfix ng sangay.

Mga sanga ng hotfix

Ang mga sanga ng hotfix ay inilaan din para sa pagpapalabas ng isang bagong bersyon sa master. Ang pagkakaiba lang ay hindi planado ang release na ito. May mga sitwasyon na ang mga depekto ay umabot sa pagpapalabas at natuklasan na sa produksyon. Halimbawa, iOS: sa sandaling maglabas sila ng bagong bersyon, makakakuha ka kaagad ng maraming update na may mga pag-aayos para sa mga depekto na natuklasan pagkatapos ng paglabas. Sa pagsasaalang-alang na ito, kinakailangan upang mabilis na ayusin ang depekto na ito at maglabas ng bagong bersyon. Sa aming larawan ito ay tumutugma sa bersyon 1.0.1. Ang ideya ay ang pagtatrabaho sa bagong pag-andar ay maaaring hindi huminto sa mga sandaling kailangan mong ayusin ang isang depekto sa isang tunay na server (tulad ng sinasabi namin, "sa produksyon": muli, isang kopya ng produksyon ng salitang Ingles). Dapat gawin ang hotfix branch mula sa master branch, dahil kinakatawan nito ang estado na gumagana sa produksyon. Sa sandaling handa na ang solusyon sa depekto, ito ay pinagsama sa master, at isang bagong label ay nilikha. Tulad ng paghahanda ng isang release branch, isang hotfix branch ay dapat na pagsamahin ang solusyon nito sa development branch.

Ang diskarte sa Forking Workflow

Bilang bahagi ng diskarte sa Forking Workflow, ang pagbuo ay isinasagawa sa paraang mayroong dalawang repositoryo:

1. Ang orihinal na repositoryo kung saan isasama ang lahat ng pagbabago.
2. Isang fork repository (ito ay isang kopya ng orihinal na repository na nasa pag-aari ng isa pang developer na gustong gumawa ng mga pagbabago sa orihinal).

Medyo kakaiba sa ngayon, tama ba? Para sa mga nakatagpo na ng open-source development, pamilyar na ang diskarteng ito. Ang diskarte na ito ay nagbibigay ng sumusunod na kalamangan: ang pag-unlad ay maaaring isagawa sa isang imbakan ng tinidor nang hindi nagbibigay ng mga karapatan sa magkasanib na pag-unlad sa orihinal. Siyempre, ang may-ari ng orihinal na repository ay may karapatang tanggihan ang mga iminungkahing pagbabago. O sumang-ayon at patayin sila. Maginhawa ito para sa parehong may-ari ng orihinal na repositoryo at sa developer na gustong lumahok sa paggawa ng ilang produkto. Halimbawa, maaari kang magmungkahi ng mga pagbabago sa Linux kernel . Kung magpasya si Linus na may katuturan sila, idadagdag ang mga pagbabago (!!!).

Ang Halimbawa ng Forking Workflow

Ang Forking Flow ay ginagamit sa GitHub kapag mayroong ilang library na gusto mong gamitin. Mayroon itong depekto na pumipigil sa paggamit nito nang buo. Sabihin nating nalaman mo nang sapat ang problema at alam mo ang solusyon. Gamit ang diskarte sa The Forking Workflow, malulutas mo ang problemang ito nang hindi nagbibigay ng mga karapatang magtrabaho sa orihinal na repositoryo ng library. Upang makapagsimula, kailangan mong pumili ng repositoryo, halimbawa, ang Spring Framework core . Hanapin ang Fork button sa kanang sulok sa itaas at i-click ito: Magtatagal ito, pagkatapos ay lalabas ang kopya ng orihinal na repositoryong ito sa iyong personal na account, na magsasaad na ito ay isang tinidor: Pagkatapos ay maaari kang magtrabaho sa repositoryong ito gaya ng dati, magdagdag ng mga pagbabago sa master branch at kapag handa na ang lahat, lumikha ng Pull-Request sa orihinal na repositoryo. Upang gawin ito, i-click ang pindutan ng Bagong Paghiling ng Pull :

Aling diskarte ang pipiliin

Ang Git ay isang flexible at makapangyarihang tool na nagbibigay-daan sa iyong magtrabaho gamit ang malawak na hanay ng mga proseso at diskarte. Ngunit kung mas malaki ang pagpipilian, mas mahirap magpasya kung aling diskarte ang pipiliin ngayon. Maliwanag, walang one-size-fits-all na sagot. Ang lahat ay depende sa sitwasyon. Gayunpaman, may ilang mga rekomendasyon na makakatulong dito:

1. Mas mabuting piliin muna ang pinakasimpleng diskarte. Lumipat sa mas kumplikadong mga diskarte lamang kung kinakailangan.
2. Isaalang-alang ang mga diskarte na may kakaunting uri ng mga sangay ng developer hangga't maaari.
3. Tingnan ang mga kalamangan at kahinaan ng iba't ibang mga diskarte at, alinsunod sa proyekto, piliin ang tama.

Iyon lang ang gusto kong sabihin sa iyo tungkol sa diskarte sa pagsasanga sa git. Salamat sa iyong atensyon :) Mag-subscribe sa aking GitHub account , madalas kong i-post ang aking trabaho doon sa iba't ibang mga teknolohiya at tool na ginagamit ko sa aking trabaho

kapaki-pakinabang na mga link

• Daloy ng GitHub: ang pinakamahusay na paraan upang magamit ang Git at GitHub
• Pull request sa GitHub o Paano ako makakagawa ng mga pagbabago sa proyekto ng ibang tao
• GitHub: Tungkol sa Pull-Requests
• Ang Tuloy-tuloy na Pagsasama, Paghahatid, at Deployment ay Naiba-iba
• Mga Pangunahing Kaalaman sa Git: Paggawa gamit ang Mga Tag
• Habr: Ang matagumpay na branching model para sa Git