Git rebase: Lahat ng Kailangan Mong Malaman

Buod: Ang utos ng Git rebase ay naglilipat ng isang sangay sa isang bagong lokasyon sa ulo ng isa pang sangay. Hindi tulad ng Git merge command, ang rebase ay nagsasangkot ng muling pagsulat ng iyong kasaysayan ng proyekto. Ito ay isang mahusay na tool, ngunit dont rebase commit iba pang mga developer ay batay sa trabaho sa.

Pinagsasama ng Git rebase ang dalawang sangay ng source code sa isa. Ang utos ng Git merge ay ginagawa rin iyon. Ipinapaliwanag namin kung ano ang ginagawa ng rebase, paano ito ginagamit, at kung kailan gagamitin ang merge sa halip.

Ang Pagsabog ng Git

Nabigo sa iba pang mga version control system at sa kanilang mabagal na pag-update at commit, si Linus Torvalds, ng Linux kernel fame, ay naglaan ng isang buwan noong 2005 para magsulat ng kanyang sarili. Pinangalanan niya itong Git.

Ang mga site tulad ng GitHub, GitLab, at BitBucket ay symbiotically nagpo-promote at nakinabang mula sa Git. Sa ngayon, ang Git ay ginagamit sa buong mundo, na may napakalaking 98 porsiyento ng 71 libong respondent sa isang survey noong 2022 gamit ang Git bilang version control system.

Ang isa sa mga pangunahing desisyon sa disenyo ng Git ay ang bilis. Sa partikular, ang pagtatrabaho sa mga sangay ay kailangang maging mas mabilis hangga't maaari. Ang mga branch ay isang pangunahing bahagi ng mga version control system. Ang isang repositoryo ng proyekto ay magkakaroon ng pangunahing o master branch. Dito matatagpuan ang code base ng proyekto. Ang pag-unlad, tulad ng mga bagong feature, ay nagaganap sa mga nakahiwalay na sanga sa gilid. Pinipigilan nito ang gawaing ginawa sa mga sangay na guluhin ang master branch, at pinapayagan nito ang sabay-sabay na pag-unlad na mangyari sa iba't ibang bahagi ng code base.

Habang nakumpleto ang mga development sa mga side branch, ang mga pagbabago ay inililipat sa master branch sa pamamagitan ng pagsasama ng development branch sa master branch. Sa iba pang bersyon ng mga control system na nagtatrabaho sa mga sangay ay mahirap at computationally mahal. Ang pagtatrabaho sa mga sangay sa Git ay napakabilis, at napakagaan. Ang dating nakakapagod at madalas na iniiwasang mag-ehersisyo sa ibang mga sistema, ay naging maliit sa Git.

Ang utos ng Git rebase ay isa pang paraan ng paglilipat ng mga pagbabago mula sa isang sangay patungo sa isa pang sangay. Ang mga command na merge at rebase ay may magkatulad na layunin, ngunit nakakamit nila ang mga layunin nito sa iba't ibang paraan at nagbubunga ng bahagyang magkaibang mga resulta.

Ano ang Git merge?

Kaya para saan ang Git merge command? Sabihin nating nakagawa ka ng branch na tinatawag na dev-branch para gumawa ng bagong feature.

Gumawa ka ng ilang commit, at subukan ang iyong bagong feature. Ang lahat ng ito ay gumagana nang maayos. Ngayon ay gusto mong ipadala ang iyong bagong feature sa master branch. Dapat ay nasa master branch ka upang pagsamahin ang isa pa dito.

Maaari naming matiyak na kami ay nasa master branch sa pamamagitan ng tahasang pagsuri nito bago kami magsama.

git checkout master

Maaari na nating sabihin sa Git na pagsamahin ang dev-branch sa kasalukuyang branch, na siyang master branch.

git merge dev-branch

Ang aming merge ay nakumpleto na para sa amin. Kung i-checkout mo ang master branch at isasama ito, magkakaroon ito ng bagong binuong feature dito. Ang aktwal na ginawa ng Git ay isang three-way merge. inihahambing nito ang pinakabagong mga commit sa master at dev-branch branch, at ang commit sa master branch kaagad bago ang dev -branch ay nilikha. Pagkatapos ay nagsasagawa ito ng commit sa master branch.

Ang mga pagsasama ay itinuturing na hindi nakakasira dahil hindi sila nagtatanggal ng anuman at hindi nila binabago ang alinman sa kasaysayan ng Git. Ang dev-branch ay umiiral pa rin, at wala sa mga nakaraang commit ang nabago. Isang bagong commit ang ginawa na kumukuha ng mga resulta ng three-way merge.

Pagkatapos ng pagsasama, ang aming Git repository ay mukhang isang timeline na may alternatibong linya na sumasanga at pagkatapos ay bumalik sa pangunahing timeline.

Ang dev-branch branch ay isinama sa master branch.

Kung marami kang sangay sa isang proyekto, maaaring maging nakalilito ang kasaysayan ng proyekto. Ito ay kadalasang nangyayari kung ang isang proyekto ay maraming nag-aambag. Dahil ang pagsisikap sa pag-unlad ay nahahati sa maraming iba't ibang mga landas, ang kasaysayan ng pag-unlad ay hindi linear. Ang pag-unntangling sa commit history ay nagiging mas mahirap kung ang mga sangay ay may sariling sangay.

Tandaan na kung mayroon kang mga hindi nakasaad na pagbabago sa master branch, kakailanganin mong gumawa ng isang bagay sa mga pagbabagong ito bago ka makapag-merge ng anuman dito. Maaari kang lumikha ng isang bagong sangay at gawin ang mga pagbabago doon, at pagkatapos ay gawin ang pagsasama. Pagkatapos, kakailanganin mong i-merge ang iyong pansamantalang branch pabalik sa master branch.

Gumagana iyon, ngunit may utos ang Git na nakakamit ang parehong bagay, nang hindi kinakailangang lumikha ng mga bagong sangay. Ang command na stash ay nag-iimbak ng iyong mga hindi naka-commit na pagbabago para sa iyo, at hinahayaan kang tawagan sila pabalik gamit ang stash pop .

Gagamitin mo ang mga ito tulad nito:

stash

git merge dev-branch

stash pop

Ang resulta ay isang pinagsamang sangay, kung saan naibalik ang iyong mga hindi na-save na pagbabago.

Ano ang Git rebase?

Ang utos ng Git rebase ay nakakamit ang mga layunin nito sa isang ganap na naiibang paraan. Kinukuha nito ang lahat ng commit mula sa branch na ire-rebase mo at ire-replay ang mga ito sa dulo ng branch kung saan ka magre-rebase.

Sa pagkuha ng aming nakaraang halimbawa, bago kami magsagawa ng anumang aksyon ang aming Git repository ay ganito ang hitsura. Mayroon kaming branch na tinatawag na dev-branch at gusto naming ilipat ang mga pagbabagong iyon sa master branch.

Pagkatapos ng rebase , mukhang isang solong, ganap na linear na timeline ng mga pagbabago.

Ang dev-branch ay tinanggal, at ang mga commit sa dev-branch ay naidagdag sa master branch. Ang huling resulta ay kapareho ng kung ang mga commit sa dev-branch ay aktwal na direktang ginawa sa master branch noong una. Ang mga commit ay hindi lang naka-tack sa master branch, ang mga ito ay nire-replay at idinagdag sariwa.

Ito ang dahilan kung bakit ang command na rebase ay itinuturing na mapanira. Ang rebased na sangay ay hindi na umiiral bilang isang hiwalay na sangay, at ang kasaysayan ng Git ng iyong proyekto ay muling naisulat. Hindi mo matukoy sa ibang pagkakataon kung aling mga commit ang orihinal na ginawa sa dev-branch.

Gayunpaman, nag-iiwan ito sa iyo ng isang pinasimple, linear, kasaysayan. Kung ikukumpara sa isang repository na may dose-dosenang o kahit na daan-daang sangay at pinagsama-sama, ang pagbabasa ng Git log o paggamit ng isang graphical na git GUI upang tingnan ang isang graph ng repositoryo, ang isang rebased na repository ay madaling maunawaan.

Paano Mag-rebase sa Ibang Sangay

Subukan natin ang isang git rebase halimbawa. Mayroon kaming proyekto na may sangay na tinatawag na new-feature. Kami ay rebase ang branch na iyon sa master branch nang ganito.

Una, tinitingnan namin na ang master branch ay walang natitirang mga pagbabago.

git status

Sinusuri namin ang new-feature branch.

git checkout new-feature

Sinasabi namin sa Git na rebase ang kasalukuyang branch sa master branch.

git rebase master

Nakikita namin na mayroon pa kaming dalawang sangay.

git branch

Nagpalit kami pabalik sa master branch

git checkout master

Pinagsasama namin ang bagong feature na branch sa kasalukuyang branch, na sa aming kaso ay ang master branch.

git merge new-feature

Kapansin-pansin, mayroon pa kaming dalawang sangay pagkatapos ng huling pagsasama.

Ang pagkakaiba ay, ngayon ang head ng new-feature branch at ang head ng master branch ay nakatakdang tumuro sa parehong commit, at ang Git history ay hindi ipakita na dati ay may hiwalay na new-feature branch, bukod sa label ng branch.

Git Rebase vs. Merge: Alin ang Dapat Mong Gamitin?

Hindi ito isang kaso ng rebase vs. merge. Pareho silang makapangyarihang mga utos at malamang na pareho mong gagamitin ang mga ito. Sabi nga, may mga kaso ng paggamit kung saan ang rebase ay hindi talaga gumagana nang maayos. Ang pag-alis ng mga pagkakamali na dulot ng mga pagkakamali sa paggamit ng merge ay hindi kasiya-siya, ngunit ang pag-alis ng mga error na dulot ng rebase ay napakasama.

Kung ikaw lang ang developer na gumagamit ng repository, mas maliit ang pagkakataong gumawa ka ng isang bagay gamit ang rebase na nakapipinsala. Maaari mo pa ring rebase sa maling direksyon halimbawa, at rebase ang iyong master branch sa iyong new-feature branch. Upang maibalik ang iyong master branch, kakailanganin mong rebase muli, sa pagkakataong ito mula sa iyong new-feature branch patungo sa iyong master sangay. Ipapanumbalik nito ang iyong master branch, kahit na may kakaibang kasaysayan.

Huwag gumamit ng rebase sa mga nakabahaging sangay kung saan malamang na magtrabaho ang iba. Ang iyong mga pagbabago sa iyong repositoryo ay magdudulot ng mga problema sa maraming tao kapag itinulak mo ang iyong rebase code sa iyong remote na imbakan.

Kung maraming contributor ang iyong proyekto, ang ligtas na gawin ay gumamit lamang ng rebase sa iyong local repository, at hindi sa mga pampublikong sangay. Gayundin, kung ang mga pull request ay bahagi ng iyong mga pagsusuri sa code, huwag gumamit ng rebase. O hindi bababa sa, huwag gumamit ng rebase pagkatapos gawin ang pull request. Malamang na tinitingnan ng ibang mga developer ang iyong mga commit, na nangangahulugan na ang mga pagbabagong iyon ay nasa pampublikong sangay, kahit na wala ang mga ito sa master branch.

Ang panganib ay ang pagpunta mo sa rebase commit na nai-push na sa isang remote na repository, at ang ibang mga developer ay maaaring nakabatay na sa trabaho sa mga commit na iyon. Gagawin ng iyong lokal na rebase ang mga umiiral nang commit na iyon. Kung itulak mo ang mga pagbabagong iyon sa repositoryo, hindi ka magiging sikat.

Ang ibang mga kontribyutor ay kailangang dumaan sa isang magulong merge upang maibalik ang kanilang trabaho sa repositoryo. Kung ibabalik mo ang kanilang mga pagbabago sa iyong lokal na imbakan, haharap ka sa pag-alis ng gulo ng mga dobleng pagbabago.

Upang Rebase, o Hindi upang Rebase?

Maaaring ipinagbabawal ang Rebase sa iyong proyekto. Maaaring may lokal, kultural na pagtutol. Itinuturing ng ilang proyekto o organisasyon ang rebase bilang isang anyo ng heresy, at isang pagkilos ng paglapastangan. Ang ilang mga tao ay naniniwala na ang kasaysayan ng Git ay dapat na isang hindi nalalabag, permanenteng tala ng kung ano ang nangyari. Kaya, maaaring wala sa talahanayan ang rebase.

Ngunit, ginagamit nang lokal, sa mga pribadong sangay, ang rebase ay isang kapaki-pakinabang na tool.

I-push pagkatapos na mag-rebase ka, at higpitan ito sa mga sangay kung saan ikaw lang ang developer. O hindi bababa sa, kung saan huminto ang lahat ng pag-unlad, at walang iba ang nagbase sa anumang iba pang gawain sa mga commit ng iyong branch.

Gawin iyon at maiiwasan mo ang anumang mga isyu.