Rebase: ano ito, pagkakaiba sa Merge at prinsipyo ng paggana

Ano ang Rebase?

Rebase (pag-rebase) — ay isang operasyon sa Git na naglilipat ng mga commit mula sa kasalukuyang branch patungo sa isang bagong reference point (base). Sa halip na lumikha ng merge commit, kinukuha ng rebase ang bawat commit mula sa source branch at isa-isang inilalapat ito sa ibabaw ng bagong base. Ang resulta ay isang linear na pagkakasunod-sunod ng mga commit nang walang pag-split.

Ang pangalang rebase ay nagmula sa „re-base" — baguhin ang base. Kung pinagsasama ng merge ang dalawang branch sa isang punto, ang rebase ay talagang naglilipat ng buong branch mo sa isang bagong lokasyon, na lumilikha ng ilusyon na sinimulan mo ang pag-develop mula sa kasalukuyang estado ng target na branch. Ito ay lumilikha ng anyo ng perpektong sunud-sunod na trabaho.

Ayon sa Atlassian, 2025, ang mga team na gumagamit ng rebase para sa feature branch ay gumugugol ng 30% mas kaunting oras sa pagsusuri ng kasaysayan ng commit kumpara sa mga team na eksklusibong gumagamit ng merge. Pinapasimple ng linear na kasaysayan ang git blame, bisect at pagtingin sa log sa pamamagitan ng git log --oneline.

Pangunahing pagkakaiba sa Merge

Merge ay pinagsasama ang mga branch sa pamamagitan ng paglikha ng commit na may dalawang magulang. Rebase ay muling nagsusulat ng kasaysayan: ang mga bagong commit ay nilikha muli na may mga bagong hash, kahit na ang mga pagbabago ay kapareho ng orihinal. Nangangahulugan ito na binabago ng rebase ang SHA identifier ng mga commit, na kritikal para sa pampublikong branch.

Paano gumagana ang Rebase

Ang mekanismo ng rebase ay binubuo ng apat na hakbang: Tinutukoy ng Git ang karaniwang ninuno (merge base) ng kasalukuyan at target na branch, pagkatapos ay inilalapat nang sunud-sunod ang bawat commit ng kasalukuyang branch sa ibabaw ng target na branch. Kung may conflict sa anumang hakbang — hihinto ang rebase at maghihintay ng solusyon.

# Panimulang sitwasyon: ang feature ay 3 commit ang layo sa develop
git checkout feature/new-login
git rebase develop

# Kinukuha ng Git ang 3 commit mula sa feature at inilalapat ang mga ito sa develop
# Kung walang conflict — awtomatikong matatapos ang rebase
# Kung mayroon — hihinto ang Git sa conflictual na commit

Pagkatapos ng rebase, ang feature branch ay naglalaman ng lahat ng commit mula sa develop kasama ang sarili nitong mga commit, na mukhang pagpapatuloy ng develop. Pinapayagan nito ang pagsasama sa develop sa pamamagitan ng fast-forward, nang hindi lumilikha ng merge commit.

Proseso hakbang-hakbang

Tingnan natin ang detalyadong halimbawa: isang developer ang lumikha ng feature branch mula sa develop, gumawa ng dalawang commit, at pansamantalang nagdagdag ang ibang developer ng tatlong commit sa develop. Ililipat ng rebase ang dalawang commit ng feature sa isang bagong lokasyon, na lumilikha ng mga kopya na may bagong SHA.

# 1. Gumawa ng feature branch
git checkout -b feature/payment-refactor develop

# 2. Gumawa ng commit sa feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. I-update ang develop (trabaho ng mga kasamahan)
git checkout develop
git pull

# 4. I-rebase ang feature sa ibabaw ng bagong develop
git checkout feature/payment-refactor
git rebase develop

# 5. Ngayon ang feature ay maaaring i-merge sa pamamagitan ng fast-forward
git checkout develop
git merge feature/payment-refactor

Kung sa hakbang 4 ay may conflict, hihinto ang Git sa problematikong commit. Nilulutas ng developer ang conflict, ginagawa ang git add at isinasagawa ang git rebase --continue. Kung kailangang laktawan ang commit — git rebase --skip, kung kanselahin ang buong rebase — git rebase --abort.

Awtomatikong paglaktaw sa walang laman na commit

Ang flag na --empty ay kumokontrol sa pag-uugali ng rebase sa mga walang laman na commit — mga sitwasyon kung saan ang lahat ng pagbabago ng commit ay nasa target na branch na. Bilang default, hihinto ang rebase at hihingi ng desisyon. Gamit ang flag na --empty=drop, awtomatikong nilalaktawan ng Git ang mga naturang commit nang hindi humihinto, na nagpapabilis sa mass rebase na may maraming commit.

Interactive na Rebase

Interactive rebase (git rebase -i) — isang makapangyarihang kasangkapan para sa pag-edit ng kasaysayan ng commit. Nagbubukas ito ng editor na may listahan ng mga commit at mga pangunahing command: pick (panatilihin), reword (baguhin ang mensahe), edit (baguhin ang nilalaman), squash (pagsamahin sa nauna), fixup (pagsamahin nang walang mensahe), drop (tanggalin).

# Interactive rebase ng huling 4 na commit
git rebase -i HEAD~4

# Sa editor ay magbubukas ang rebase plan:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Pinapalitan namin sa:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Resulta: tatlong commit (login screen, validation, layout) ay pinagsama sa isa, at ang commit na may mga komento ay tinanggal. Pinapayagan nito ang paghahain ng malinis na kasaysayan nang walang draft at pagwawasto para sa code review. Ang interactive rebase ay ang karaniwang kasangkapan para sa paghahanda ng feature branch bago ang Pull Request.

Rebase vs Merge: paghahambing

Rebase at Merge ay lumulutas ng parehong gawain — pagsasama ng mga pagbabago — ngunit sa magkaibang paraan. Ang pagpili sa pagitan ng mga ito ay depende sa kung anong uri ng kasaysayan ang gusto mong makita sa git log at kung sino pa ang nagtatrabaho sa iyong branch.

Praktikal na patakaran: gamitin ang merge para sa pagsasama sa karaniwang branch (develop, main) at rebase para sa pag-update ng personal na feature branch sa kasalukuyang estado. Maraming team ang nagsasama: rebase feature sa develop, pagkatapos --no-ff merge sa develop.

Epekto sa git bisect

Git bisect — isang kasangkapan para sa paghahanap ng commit na nagpakilala ng regression. Kapag gumagamit ng merge, tama na dumadaan ang git bisect sa mga merge commit, isinasaalang-alang ang parehong magulang. Sa rebase, mas mabilis gumana ang bisect dahil linear ang kasaysayan at hindi nangangailangan ng pag-split. Gayunpaman, kung ginawa ang rebase pagkatapos malaman ng team ang mga commit, nawawala ang orihinal na SHA at maaaring hindi mahanap ng bisect ang problematikong commit.

Kailan gagamitin ang Rebase

Rebase ay optimal sa tatlong sitwasyon: paghahanda ng feature branch para sa Pull Request, pag-update ng personal na branch sa kasalukuyang estado ng main/develop at paglilinis ng kasaysayan bago ang pagsasama. Sa bawat kaso, pinapabuti ng rebase ang pagbabasa ng kasaysayan nang walang panganib para sa gawaing pang-team.

Bago ang Pull Request ay inirerekomenda na magsagawa ng interactive rebase upang pagsamahin ang mga working commit (WIP, pagwawasto pagkatapos ng review) sa makabuluhang lohikal na yunit. Pinapadali nito ang code review: ang reviewer ay nakakakita hindi 15 maliit na commit, kundi 3-5 nakabalangkas na pagbabago na may malinaw na mensahe.

Para sa pag-update ng feature branch, mas pinipili ang rebase kaysa merge dahil hindi ito lumilikha ng mga hindi kinakailangang merge commit. Kung pana-panahon kang gumagawa ng git rebase develop sa loob ng feature branch, pagkatapos ng huling pagsasama ay walang kaskad ng 10 merge commit — malinis lamang na feature commit sa ibabaw ng develop.

Paglilinis ng kasaysayan sa pamamagitan ng interactive rebase bago ang pagsasama ay nagbibigay-daan sa pagtatago ng maliliit na pagwawasto (typographical error, formatting) at pagpapangkat ng mga commit ayon sa functionality. Ang mga mensahe ng Git ay dapat sumunod sa kasunduan ng Conventional Commits (fix:, feat:, refactor:, docs:), na bumubuo ng awtomatikong changelog.

Mga panganib at patakaran ng Rebase

Rebase — isang mapanganib na operasyon kung maling inilapat. Ang pangunahing panganib — muling pagsulat ng na-publish na kasaysayan. Kung ang isang developer ay nag-rebase ng branch na na-push na at ginagamit ng iba, ang kanilang lokal na kopya ay ma-de-synchronize at kailangan nilang gumawa ng force-pull na may panganib ng pagkawala ng data.

• Gintong patakaran: huwag kailanman i-rebase ang mga commit na mayroon na sa shared repository. Ito ay nalalapat sa anumang branch na may access ang ibang miyembro ng team
• Force push: pagkatapos ng rebase ng lokal na feature branch, kinakailangan ang push na may flag na --force-with-lease, na mas ligtas kaysa --force dahil tinitingnan nito kung may nag-update ng branch sa server
• Pagkawala ng konteksto: sinisira ng rebase ang impormasyon tungkol sa kung kailan at mula sa aling branch nilikha ang feature branch. Kung mahalaga na panatilihin ang petsa ng paggawa ng branch — gamitin ang merge
• Mga conflict: sa rebase, ang mga conflict ay dapat lutasin para sa bawat commit nang hiwalay, na maaaring nakakapagod sa maraming commit

Para sa pag-minimize ng panganib, sundin ang patakaran: rebase lamang para sa personal na branch na hindi na-publish. Kung ang branch ay nasa shared repository na — gamitin ang merge na may --no-ff. Kung kinakailangan ang rebase ng nai-publish na branch — balaan ang team at i-coordinate ang force push nang maaga.

Awtomatikong proteksyon laban sa mapanganib na rebase ay naisasagawa sa pamamagitan ng server-side hooks: maaaring suriin ng pre-receive hook sa panig ng Git server kang ang push ay muling nagsusulat ng mga nai-publish na commit. Ang GitHub at GitLab ay nagbibigay ng built-in na proteksyon para sa protected branch — ang force push ay naka-block kung hindi inalis ang proteksyon ng administrator.