Rebase: ano ito, paano gumagana ang rebase at pagtatrabaho sa Git

Ano ang rebase sa Git

Rebase — ay isang command ng Git na nagre-rebase sa kasalukuyang branch sa tinukoy na branch: kinukuha ang lahat ng commit ng kasalukuyang branch, pansamantalang iniimbak ang mga ito, inililipat ang pointer ng branch sa target na commit at sunud-sunod na inilalapat ang mga nakaimbak na commit sa ibabaw nito. Resulta — ang kasaysayan ay mukhang ang developer ay nagtrabaho nang direkta mula sa huling commit ng target na branch.

Pangunahing syntax: git rebase main — habang nasa feature-branch, ang command na ito ay naglilipat ng lahat ng feature commit sa tuktok ng main. Gumagamit ang Git ng three-way merge strategy para sa bawat commit nang hiwalay. Kung ang commit A ay nasa target na branch na (natukoy sa pamamagitan ng hash), awtomatikong nilalaktawan ito ng Git, na umiiwas sa pagdodoble ng mga pagbabago.

Sinusuportahan din ng rebase ang onto mode para sa paglipat ng bahagi ng mga commit: git rebase --onto target start end — ang form na ito ay nagbibigay-daan kumuha ng hanay ng mga commit mula sa isang branch at ilapat ang mga ito sa ibabaw ng isa pa. Halimbawa, ang git rebase --onto main feature~3 feature ay maglilipat ng huling tatlong commit ng feature-branch sa tuktok ng main.

# Lumipat sa feature branch
git checkout feature

# I-rebase ang feature sa main
git rebase main

# Pagkatapos ng matagumpay na rebase — linear ang kasaysayan
git log --oneline --graph

# Ilipat ang huling 3 commit sa main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: pangunahing pagkakaiba

Rebase at merge ay lumulutas ng parehong gawain — pagsasama ng mga pagbabago mula sa iba’t ibang branch — ngunit ginagawa ito sa magkaibang paraan. Pinapanatili ng merge ang kumpletong kasaysayan ng pagsasama sa pamamagitan ng paglikha ng merge-commit na may dalawang parent. Ang rebase ay muling nagsusulat ng kasaysayan, ginagawa itong linear. Ang pagpili sa pagitan nila ay depende sa workflow ng team at mga patakaran sa pagtatrabaho sa repository.

Ang pangunahing pagkakaiba — paano naitala ang katotohanan ng pagsasama. Iningatan ng merge: “sa puntong ito pinagsama namin ang feature sa main” — ito ay nagbibigay-kaalaman para sa kasaysayan ng proyekto, ngunit nagpapalibog sa log sa madalas na pagsasama. Ipinapakita ng rebase: “ang mga feature commit ay ginawa nang sunud-sunod mula sa huling estado ng main” — ito ay malinis, ngunit itinatago ang katotohanan na ang trabaho ay ginawa nang magkatulad.

Ang pangalawang pagkakaiba — paghawak ng conflict. Sa merge, ang conflict ay nilulutas nang isang beses at ang solusyon ay naitala sa merge-commit. Sa rebase, ang conflict ay maaaring lumitaw para sa bawat inilipat na commit at bawat isa ay nangangailangan ng hiwalay na paglutas. Ito ay mas matrabaho, ngunit nagbibigay-daan sa mas tumpak na kontrol sa kung aling mga pagbabago ang napupunta sa huling bersyon.

Interactive na rebase: mga command at flag

Interactive na rebase (git rebase -i) — ay mode kung saan binubuksan ng Git ang editor na may listahan ng mga commit at mga available na aksyon para sa bawat isa. Maaaring muling isulat ng developer ang kasaysayan bago ipadala sa malayuang repository. Ito ang pangunahing tool para mapanatili ang kalinisan ng mga commit sa feature-branch.

Mga available na command sa interactive mode: pick (iwan ang commit kung ano ito), reword (baguhin ang mensahe ng commit), edit(huminto para sa mga pagbabago), squash (pagsamahin sa naunang commit, panatilihin ang parehong mensahe), fixup (pagsamahin, itapon ang mensahe), drop (tanggalin ang commit). Bawat command ay ipinapakita bago ang hash ng commit sa bukas na editor.

Squash at fixup — ang pinakamadalas gamitin na command para pagsamahin ang mga commit. Kung ang developer ay gumawa ng 5 maliit na commit na may mga pagwawasto sa proseso ng trabaho, pagsasamahin sila ng squash sa isang lohikal na commit na may makabuluhang mensahe. Ang fixup ay kapaki-pakinabang para sa pagwawasto ng typo: ang mga pagbabago ay napupunta sa naunang commit nang hindi iniimbak ang sarili nitong mensahe.

# Buksan ang editor para sa huling 4 na commit
git rebase -i HEAD~4

# Ipapakita ng editor ang:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# Pagkatapos i-save — Ginagawa ng Git ang rebase
# at bubuksan ang editor para sa pinagsamang commit message

# Auto-squash nang hindi binubuksan ang editor
git rebase -i HEAD~4 --autosquash

Ang flag na --autosquash ay awtomatikong nagtatakda ng fixup/squash para sa mga commit na ang mensahe ay nagsisimula sa fixup! o squash!. Pinapabilis nito ang trabaho kung minamarkahan ng developer ang mga commit nang maaga para sa susunod na pagsasama. Ang flag na --committer-date-is-author-date ay pinapanatili ang orihinal na petsa ng commit sa rebase — kapaki-pakinabang para mapanatili ang kronolohiya sa kasaysayan.

Paglutas ng conflict sa rebase

Conflict sa rebase ay nangyayari kapag hindi awtomatikong mailalapat ng Git ang inilipat na commit dahil sa pagkakasalungat sa mga pagbabago sa target na branch. Hindi tulad ng merge kung saan ang conflict ay nireresolba nang isang beses, sa rebase ang bawat commit ay maaaring magdulot ng conflict at kailangang lutasin nang sunud-sunod para sa bawat commit mula sa pinakaluma hanggang sa pinakabago.

Kapag may conflict, ipinapatigil ng Git ang rebase at iniuulat kung aling commit ang nagdulot ng problema. Binubuksan ng developer ang conflict na file (minamarkahan ng Git ang mga conflict area gamit ang markers <<<<<<<, =======, >>>>>>>), ine-edit ito, idinaragdag sa index (git add) at ipinagpapatuloy ang rebase gamit ang command na git rebase --continue. Kung walang makitang solusyon — ganap na kinakansela ng git rebase --abort ang rebase.

Tip: sa maraming conflict, mas epektibong gamitin ang git mergetool na nagbubukas ng visual editor para sa paglutas ng mga pagkakasalungat. Maaari ring laktawan ang problematikong commit (git rebase --skip), ngunit tatanggalin nito ang mga pagbabago nito mula sa huling kasaysayan, na bihirang tamang solusyon.

# Simulan ang rebase na may conflict
git rebase main
# Auto-merging file.txt
# CONFLICT (nilalaman): Conflict sa pagsasama sa file.txt

# Suriin ang status
git status
# parehong binago: file.txt

# I-edit ang mga conflict section → git add → magpatuloy
git add file.txt
git rebase --continue

# Kung hindi sigurado — kanselahin
git rebase --abort

Kailan hindi dapat mag-rebase

Golden rule ng rebase: huwag kailanman i-rebase ang mga commit na naipadala na sa malayuang repository at available sa ibang developer. Dahil ang rebase ay muling nagsusulat ng mga hash ng commit, ang mga kasamahan ay makakaranas ng conflict sa pag-sync — ang kanilang lokal na kasaysayan ay hindi tutugma sa muling isinulat na malayuang kasaysayan.

Sitwasyon kung saan ang rebase ay tiyak na ipinagbabawal: kung may lumikha na ng branch batay sa iyong mga commit (halimbawa, ang iyong kasamahan ay gumawa ng feature mula sa iyong feature), ang pagbabago ng kasaysayan ay masisira ang kanyang trabaho. Sa ganitong mga kaso, dapat gamitin ang merge. Hindi rin inirerekomenda na mag-rebase bago ang deadline — ang pagkakamali sa paglutas ng conflict ay maaaring tumagal nang mas matagal kaysa inaasahan at harangan ang release.

Exception: kung ang branch ay ginagamit lamang ng isang developer (personal na feature-branch, hindi nai-publish o nai-publish sa draft mode), ang rebase bago ang push ay standard na praktika. Pagkatapos ng publikasyon at pagsisimula ng sama-samang trabaho — tanging merge. Ang GitHub at GitLab bilang default ay nag-aalok ng squash merge bilang kompromiso: pinagsasama nito ang mga commit sa isa, ngunit hindi nito isinusulat muli ang kasaysayan ng target na branch.

• Pampublikong branch (main, develop, release) — ganap na ipinagbabawal ang rebase.
• Commit ng iba — kung ang branch ay naglalaman ng commit ng ibang developer, hindi pinapayagan ang rebase.
• Bago ang release — mas mataas ang panganib ng conflict: ang merge ay mas ligtas isang araw bago ang deadline.
• Branch na may tag — ang paglipat ng commit na may tag ay lumalabag sa mga convention ng semantic versioning.
• CI/CD na naka-link sa hash — ilang deployment system ang nag-iidentify ng build sa pamamagitan ng commit hash; sisirain ng rebase ang tracking.

Praktikal na workflow sa rebase

Sa mga modernong team, kadalasang ginagamit ang rebase-oriented workflow kasama ang GitHub Flow. Ganito ang proseso: ang developer ay gumagawa ng feature-branch mula sa main, nagtatrabaho dito, pana-panahong nag-sa-sync sa pamamagitan ng git rebase main, at bago gumawa ng pull request ay nagsasagawa ng interactive na rebase para linisin ang kasaysayan.

Pagkatapos gumawa ng PR (kung kailangan kunin ang mga bagong pagbabago mula sa main) ay ginagamit ang git pull --rebase main sa halip na ordinaryong git pull. Ito ay nagbibigay-daan kunin ang mga pagbabago nang hindi lumilikha ng hindi kinakailangang merge-commit. Ang git pull na may flag na --rebase ay katumbas ng git fetch + git rebase — unang naglo-load ang Git ng mga bagong commit, pagkatapos ay ire-rebase ang mga lokal na pagbabago sa ibabaw ng mga ito.

Pinapayagan ng Git na itakda ang rebase bilang default na pag-uugali para sa pull: git config --global pull.rebase true. Pagkatapos ng configuration na ito, ang git pull ay palaging gumagawa ng rebase sa halip na merge. Kung kailangan ang ordinaryong pull — ginagamit ang git pull --no-rebase. Maraming team ay nag-a-activate din ng autostash: git config --global rebase.autoStash true — ito ay awtomatikong nagtatago ng hindi pa nacocommit na mga pagbabago bago ang rebase at ibinabalik ang mga ito pagkatapos.