Merge — ano ito, mga uri ng pagsasama at mekanismo ng paggana

Ano ang Merge?

Merge (pagsasama) — ay isang pangunahing operasyon sa Git na pinagsasama ang mga pagbabago mula sa isang branch (source) papunta sa isa pa (target). Bilang resulta ng pagsasama, natatanggap ng target branch ang lahat ng commit mula sa source branch na wala pa rito. Depende sa sitwasyon, maaaring isagawa ng Git ang merge sa tatlong magkakaibang paraan.

Ang pangunahing halaga ng merge ay ang pagpapanatili ng kasaysayan: ang merge commit ay nagtatala ng katotohanan ng pagsasama ng mga branch, nag-iimbak ng impormasyon tungkol sa kung kailan at aling mga branch ang pinagsama. Ito ay nagpapadali sa audit ng mga pagbabago, paghahanap ng mga regression, at pag-unawa sa kronolohiya ng pag-develop. Sa malalaking proyekto, ang merge commit ay ang karaniwang paraan ng integrasyon ng code.

Ayon sa datos ng GitLab Flow, ang mga merge commit ay ginagamit sa 73% ng mga team na nagtatrabaho sa Git. Ang mga alternatibong approach (rebase, squash) ay ginusto ng mga team na nakatuon sa linear na kasaysayan. Ang pagpili ng estratehiya ay depende sa laki ng team, dalas ng release, at mga kasunduang tinanggap sa proyekto.

Kailan kinakailangan ang Merge

Merge ay kinakailangan kapag natapos na ng developer ang trabaho sa isang feature at nais itong isama sa develop o main. Karaniwang sitwasyon: ang developer ay lumikha ng feature branch mula sa develop, nagtrabaho dito ng ilang araw, at sa panahong ito ay lumitaw ang mga bagong commit sa develop mula sa ibang mga kalahok. Bago ang pagsasama, kailangang pagsamahin ang mga pagbabago — at para dito ginagamit ang merge.

Kung walang merge, hindi posible ang pagtutulungan sa isang code sa Git. Bawat oras na ang dalawang developer ay sabay na gumagawa ng mga pagbabago sa parehong codebase, ang kanilang mga branch ay nagdi-diverge. Ang Merge — ay ang tanging paraan upang pagsamahin muli ang mga pagbabagong ito nang walang pagkawala ng datos.

Mga uri ng pagsasama sa Git

Sinusuportahan ng Git ang tatlong uri ng merge, bawat isa ay nakatuon sa sarili nitong sitwasyon. Ang pagpili ng uri ng pagsasama ay nakakaapekto sa kasaysayan ng commit, kaginhawaan ng pag-rollback, at pagiging nababasa ng log.

Fast-forward merge

Fast-forward ay nangyayari kapag ang target branch ay walang bagong commit mula nang likhain ang source branch. Sa kasong ito, inililipat lamang ng Git ang pointer ng target branch pasulong, sa huling commit ng source branch. Ang kasaysayan ay nananatiling linear, walang merge commit.

# Fast-forward merge: ang develop ay hindi nagbago mula nang likhain ang feature
git checkout develop
git merge feature/new-login

# Resulta: ang pointer ng develop ay lumipat sa dulo ng feature
# Walang merge commit na ginawa

Ang Fast-forward ay maginhawa para sa maikli ang buhay na mga branch, kung saan ang developer ay nagtrabaho mag-isa. Ngunit ang approach na ito ay may kakulangan: nawawala ang impormasyon na ang branch ay umiral — lahat ng commit ay mukhang direktang ginawa sa develop.

Three-way merge

Three-way merge ay isinasagawa kapag ang parehong branch ay may bagong commit pagkatapos ng divergence point. Gumagawa ang Git ng isang hiwalay na merge commit na may dalawang magulang, na nagtatala ng katotohanan ng pagsasama ng mga branch. Ang approach na ito ay inirerekomenda para sa mga feature branch sa pag-develop ng team.

# Puwersahang three-way merge gamit ang flag na --no-ff
git checkout develop
git merge --no-ff feature/new-login

# Merge commit na ginawa na may default na mensahe
# Maaaring magtakda ng sariling mensahe sa pamamagitan ng -m
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

Ang flag na --no-ff ay ginagarantiyahan ang paglikha ng merge commit, kahit na posible ang fast-forward. Ito ang pinakamahusay na kasanayan para sa pagpapanatili ng impormasyon tungkol sa branching sa proyekto.

Squash merge

Squash merge ay pinipiga ang lahat ng commit ng source branch sa isa at inilalapat ito sa target branch. Nawawala ang kasaysayan ng feature — isang commit na may lahat ng pagbabago ang pumapasok sa branch. Ito ay maginhawa kapag ang mga detalyadong commit sa feature branch ay hindi nagdadala ng halaga sa pangkalahatang kasaysayan.

# Squash merge: lahat ng commit ng feature ay piniga sa isa
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash ay angkop para sa mga draft, eksperimental na branch, at mga sitwasyon kung saan mahalaga ang pagpapanatili ng kalinisan ng kasaysayan. Minus — nawawala ang koneksyon sa orihinal na mga commit, na nagpapahirap sa pag-rollback ng mga indibidwal na pagbabago.

Mga estratehiyang Ours at Theirs

Ours at Theirs — dalawang espesyal na estratehiya ng merge sa Git. Ang Ours ay ganap na binabalewala ang mga pagbabago mula sa source branch, pinapanatili lamang ang nasa target branch. Ang Theirs naman ay tinatanggap ang bersyon ng source branch sa anumang conflict. Ang mga estratehiyang ito ay kapaki-pakinabang sa pagsasama ng malalaking volume ng code, kapag alam nang maaga kung aling bersyon ang dapat manalo.

Paano gumagana ang Merge

Ang mekanismo ng merge sa Git ay batay sa paghahambing ng tatlong punto: ang karaniwang ninuno (merge base), ang estado ng source branch, at ang estado ng target branch. Hinahanap ng Git ang merge base — ang huling commit na karaniwan sa parehong branch — at kinakalkula kung anong mga pagbabago ang naganap sa bawat branch pagkatapos ng divergence.

• Hakbang 1 — Tinutukoy ng Git ang merge base: ang huling commit na nasa parehong branch
• Hakbang 2 — Gumagawa ang Git ng dalawang diff: mula merge base papuntang source at mula merge base papuntang target
• Hakbang 3 — Sinusubukan ng Git na ilapat ang parehong set ng pagbabago sa merge base
• Hakbang 4 — Kung hindi nagkakasalungat ang mga pagbabago — awtomatikong nagtatapos ang merge
• Hakbang 5 — Kung may conflict — humihinto ang Git at humihingi ng paglutas

Gumagamit ang Git ng tatlong-direksyong algorithm ng pagsasama, na isinasaalang-alang hindi lamang ang dalawang pinaghahambing na bersyon ng file, kundi pati na rin ang kanilang karaniwang ninuno. Dahil dito, maaaring awtomatikong lutasin ng Git ang mga sitwasyon kung saan ang mga pagbabago sa isang branch ay hindi naaapektuhan ang mga binagong bahagi ng isa pa — kahit na ang parehong file ay binago.

Algorithm ng paggana ng merge sa pamamagitan ng halimbawa

Isaalang-alang ang sitwasyon: dalawang developer ang nagtatrabaho sa magkaibang file sa parehong feature branch. Binago ng una ang LoginActivity.kt, ng pangalawa — ang ProfileFragment.kt. Kapag pinagsama nila ang kanilang mga pagbabago, nakikita ng Git na ang mga pagbabago ay tumutukoy sa magkaibang file at awtomatikong isinasagawa ang merge, nang walang interbensyon ng tao.

Kung ang parehong developer ay nagbago ng LoginActivity.kt, ngunit sa magkaibang mga metodo — hahawakan din ito ng Git nang awtomatiko, pinagsasama ang mga pagbabago linya sa linya. Ang conflict ay lumilitaw lamang kung pareho silang nagbago ng parehong mga linya o kung ang isa ay nagtanggal ng code na binago ng isa.

Paglutas ng mga conflict sa Merge

Ang conflict ng merge ay lumilitaw kapag hindi awtomatikong pagsamahin ng Git ang mga pagbabago, dahil ang parehong branch ay nagbago ng parehong mga linya sa magkaibang paraan. Sa kasong ito, minamarkahan ng Git ang mga bahaging may conflict sa mga file at naghihintay ng manu-manong paglutas ng developer.

Ang mga bahaging may conflict ay minamarkahan ng mga espesyal na marker: <<<<<<< HEAD ay nagpapakita ng code mula sa target branch, ======= — ang separator, >>>>>>> source-branch — code mula sa source branch. Dapat piliin ng developer nang manu-mano kung aling variant ang pananatilihin o pagsamahin ang mga ito.

# 1. Patakbuhin ang merge at makita ang conflict
git merge feature/new-login
# Output: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. Tingnan ang listahan ng mga file na may conflict
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. Lutasin ang conflict: i-edit ang file, alisin ang mga marker
# 4. Idagdag ang nalutas na file at tapusin ang merge
git add src/ui/login/LoginActivity.kt
git merge --continue
# o: git commit (walang --continue)

Para sa paglutas ng mga conflict, may mga kasangkapan: ang git mergetool ay nagbubukas ng visual merger (Meld, Beyond Compare, VS Code). Maraming developer ang mas gustong lutasin ang mga conflict sa IDE — ang IntelliJ IDEA at Android Studio ay nagbibigay ng built-in na kasangkapan na may tatlong-panel na paghahambing, na makabuluhang pinapasimple ang prosesong ito.

Mga tip para sa paglutas ng conflict: laging unawain kung ano ang ginagawa ng bawat panig ng conflict, huwag tanggalin ang code ng iba nang hindi nauunawaan ang lohika nito, at kung ang conflict ay masyadong komplikado — isama ang may-akda ng parehong branch sa magkasanib na paglutas.

Merge vs Rebase: kailan pipili ng ano

Ang pagpili sa pagitan ng Merge at Rebase — isa sa mga pinakakaraniwang desisyong arkitektural sa Git. Pinagsasama ng parehong approach ang mga pagbabago, ngunit ginagawa nila ito sa magkaibang paraan: ang merge ay nagpapanatili ng kasaysayan ng branching, ang rebase ay muling nagsusulat ng kasaysayan, ginagawa itong linear.

• Merge — nagpapanatili ng konteksto: nakikita kung kailan at mula sa aling branch ginawa ang pagsasama. Mas mabuti para sa pampublikong branch (develop, main) at pagtutulungan ng team
• Rebase — lumilikha ng malinis na linear na kasaysayan walang mga hindi kinakailangang merge commit. Mas mabuti para sa personal na feature branch bago ipadala para sa review
• Patakaran: huwag kailanman mag-rebase ng pampublikong branch na ginagamit ng ibang developer

Maraming team ang gumagamit ng hybrid approach: rebase para dalhin ang feature branch sa kasalukuyang estado ng develop (git rebase develop), pagkatapos ay merge na may flag na --no-ff para itala ang pagsasama. Ito ay nagbibigay ng malinis na kasaysayan sa loob ng feature at nagbibigay-kaalaman na mga punto ng pagsasama sa antas ng develop.