3.4 Pag-branch ng Git - Mga Daloy ng Trabaho sa Pag-branch

Dahil ang Git ay gumagamit ng isang simpleng three-way na merge, ang pag-merge mula sa isang branch patungo sa iba pa nang maraming beses sa isang mahabang panahon ay kadalasang madaling gawin. Ang ibig sabihin nito ay maaari kang magkaroon ng iilang mga branch na palaging nakabukas at magagamit mo sa iba’t ibang mga yugto ng iyong development cycle; maaari kang regular na mag-merge mula sa ilan sa kanila patungo sa mga iba pa.

Karamihan sa mga developer ng Git ay mayroong isang daloy ng trabaho na tumatanggap ng ganitong paraan, katulad ng pagkakaroon ng code na buong matatag sa kanilang master na branch — posibleng code lamang na na-release o iri-release. Mayroon silang ibang kahilera na branch na nakapangalang develop o next na tinatrabaho nila o ginagamit upang i-test ang katatagan — ito ay hindi kinakailangang palaging matatag, ngunit tuwing ito ay makakakuha ng isang matatag na estado, maaari itong i-merge sa master. Ginagamit ito upang maka-pull sa paksa na mga branch (maikling buhay na mga branch, katulad ng iss53 na branch kamakailan lamang) kapag handa na ang mga ito, upang siguraduhing sila ay pasado sa lahat ng mga pagsubok at hindi magpapakilala ng mga bug.

Sa katunayan, tinatalakay natin ang tungkol sa mga pointer na lumilipat paitaas sa linya ng mga commit na iyong ginagawa. Ang matatag na mga branch ay mas malayo sa ibaba sa linya ng iyong kasaysayang ng commit, at ang pinakabago na mga branch ay malayo sa itaas ng kasaysayan.

Ito ay karaniwang mas madaling pag-isipan tungkol sa kanila bilang mga lalagyan ng trabaho, kung saan ang mga pangkat ng commit ay magtatapos sa isang mas matatag na lalagyan kapag sila ay ganap nang nasubukan.

Maaari kang manatiling gumawa nito sa ilang mga antas ng stabilidad. Ilang mas malaking mga proyekto ay mayroon ding proposed o pu (iminungkahi na mga update) na branch na may napagsama-sama na mga branch na maaaring hindi pa handang pumunta sa next o master na branch. Ang ideya nito ay ang iyong mga branch ay nasa iba’t ibang antas ng stabilidad; kapag nakaabot sila sa isang mas matatag na antas, sila ay imi-merge sa branch na nasa itaas nila. Muli, ang pagkakaroon ng maramihang matagal na tumatakbong mga branch ay hindi kinakailangan, ngunit ito ay kadalasang kapaki-pakinabang, lalo na kapag ikaw ay nakikipagtungo sa sobrang malaki o kumplikadong mga proyekto.

Ang paksa na mga branch, gayunpaman, ay kapaki-pakinabang sa mga proyekto sa anumang laki. Isang paksa na branch ay isang maikling-buhay na branch na ginagawa mo at gagamitin para sa isang solong partikular na tampok o may kaugnayan na trabaho. Ito ay isang bagay na malamang na hindi mo pa nagawa gamit ang isang VCS dati dahil ito ay kadalasang sobrang magastos upang ilikha at i-merge sa mga branch.

Nakita mo ito sa huling seksyon sa iss53 at hotfix na mga branch na iyong ginawa. Gumawa ka ng ilang mga commit sa mga iyon at direktang binura ang mga iyon pagkatapos mong i-merge ang mga ito sa iyong pangunahing branch. Ang pamamaraang ito ay nagpapahintulot sa iyo upang mag context-switch nang mabilis at ganap — dahil ang iyong trabaho ay hiwalay sa mga silo kung saan lahat ng mga pagbabago sa branch na iyo ay may gagawin sa paksang iyon, mas madaling tingnan kung ano ang nangyari sa panahon ng code review at ganoon. Maaari mong panatilihin ang mga pagbabago doon sa ilang mga minuto, mga araw, o mga buwan, at i-merge in ang mga iyon kapag sila ay handa na, kahit sa anumang pagkakaayos sila nabuo o tinrabaho.

Isaalang-alang ang isang halimbawa sa paggawa ng ilang trabaho (sa master), pag-branch off para sa isang isyu (iss91), pagtatrabaho nito sa isang saglit, pag-branch off sa pangalawang branch upang subukan ang ibang paraan ng pag-asikaso ng parehong bagay (iss91v2), pagpunta pabalik sa iyong master na branch at pagtatrabaho dito sa mahabang sandali, at pagkatapos ay mag-branch off doon para gumawa ng ilang trabaho na hindi ka siguradong isang magandang ideya (dumbidea na branch). Ang iyong kasaysayan ng commit ay magmumukhang katulad nito:

Ngayon, sabihin nating ikaw ay nakapagpasya na pinakagusto mo ang pangalawang solusyon sa iyong isyu (iss91v2); at ipinakita mo ang dumbidea na branch sa iyong katrabaho, and ito ay napatunayang henyo. Maaari mong itapon ang orihinal na iss91 na branch (mawawala ang mga commit na C5 at C6) at i-merge in ang dalawang iba pa. Ang iyong kasaysayan ngayon ay magmumukhang katulad nito:

Pupunta tayo sa mas maraming detalye tungkol sa iba’t ibang posibleng mga daloy ng trabaho para sa iyong Git na proyekto sa Distributed Git, kaya bago ka makapagpasya kung anong pamamaraan ng pag-branch ang gagamitin ng iyong susunod na proyekto, siguraduhing basahin ang kabanatang iyon.

Importanteng tandaan tuwing ginagawa mo lahat ng mga ito na ang mga branch na ito ay ganap na lokal. Kapag ikaw ay nag-branch at nag-merge, ang lahat ng bagay ay tinatapos lamang sa iyong Git na repositoryo — walang server na komunikasyon ang nagaganap.