Pagsasama (merge) — ano ito, paano gumagana ang merge at mga estratehiya ng pagsasama

Ano ang merge sa Git

Merge — ito ay ang utos na git merge na pinagsasama ang mga pagbabago mula sa tinukoy na sangay patungo sa kasalukuyang sangay. Hinahanap ng Git ang karaniwang ninuno (common base commit), kinakalkula ang diff ng bawat sangay kaugnay sa ninuno, at lumikha ng merge-commit na naglalaman ng pinagsamang hanay ng mga pagbabago. Resulta — ang target na sangay ay napupunan ng lahat ng pagbabago mula sa pinagsamang sangay.

Syntax: habang nasa target na sangay (hal. main), isagawa ang git merge feature. Awtomatikong gumagawa ang Git ng merge-commit kung walang conflict. Sa default na mensahe ng merge-commit ay nakasulat: “Merge branch ’feature’ into main”. Maaaring baguhin ang mensahe sa pamamagitan ng flag -m o i-edit sa binuksang editor.

Ang merge ay isang hindi-mapanirang operasyon. Hindi tulad ng rebase, hindi ginagalaw ng merge ang mga umiiral na commit: nananatili sila sa parehong hash, may-akda, at petsa. Ginagawa nitong ang merge ang tanging ligtas na paraan ng pagsasama para sa mga sangay na sabay na ginagamit ng maraming developer. Kung may mali, maaaring kanselahin ang merge gamit ang utos na git merge --abort.

# Lumipat sa target na sangay
git checkout main

# Pagsamahin ang feature na sangay
git merge feature

# Resulta — merge-commit na may dalawang magulang
git log --oneline --graph

# Pagsamahin na may custom na mensahe
git merge feature -m "feat: integrate authentication module"

Mga uri ng merge: regular, squash, fast-forward

Sinusuportahan ng Git ang tatlong mode ng pagsasama, na pinipili depende sa nais na resulta. Ang regular merge (default) ay lumikha ng merge-commit. Ang squash merge ay pinagsasama ang lahat ng commit ng feature na sangay sa iisa. Fast-forward — inililipat ang pointer ng sangay nang hindi lumilikha ng commit, kung posible. Ang pagpili ng mode ay depende sa workflow ng team at mga patakaran ng kasaysayan.

Regular merge (--no-ff) — lumikha ng merge-commit kahit na ang pagsasama ay maaaring isagawa bilang fast-forward. Inirerekomenda para sa main na sangay: ang merge-commit ay malinaw na minamarka ang sandali ng integrasyon ng feature at nagpapahintulot ng madaling pagbalik ng lahat ng pagbabago ng feature na sangay sa pamamagitan ng isang revert ng merge-commit. Ginagamit ng GitHub ang mode na ito bilang default kapag pinagsasama ang PR sa pamamagitan ng Merge button.

Squash merge (--squash) — kinokolekta ang lahat ng commit ng feature na sangay sa iisang commit sa target na sangay. Kapaki-pakinabang kapag ang magaspang na kasaysayan ng feature na sangay ay hindi dapat pumasok sa main. Disadvantage: nawawala ang koneksyon sa orihinal na mga commit — hindi makikita kung paano binuo ang feature nang hakbang-hakbang. Ginagamit ng GitHub ang mode na ito kapag pinili ang “Squash and merge” sa PR.

Fast-forward (--ff) — kung ang target na sangay ay walang bagong commit pagkatapos ng pagsanga ng feature, simpleng inililipat ng Git ang pointer pasulong, nang hindi lumilikha ng merge-commit. Nananatiling linear ang kasaysayan. Ang flag --no-ff ay pinipilit ang paglikha ng merge-commit, ang --ff-only ay magtatapos sa error kung hindi posible ang fast-forward.

# Pilitin ang merge-commit (inirerekomenda para sa main)
git merge --no-ff feature

# Squash merge — lahat ng commit sa iisa
git merge --squash feature
git commit -m "feat: add authentication"

# Fast-forward lamang kung posible
git merge --ff-only feature

# Kanselahin ang may conflict na merge
git merge --abort

Mga estratehiya ng pagsasama ng Git

Ang mga estratehiya ng pagsasama ay tumutukoy sa algorithm na ginagamit ng Git para pagsamahin ang mga pagbabago. Bawat estratehiya ay angkop para sa iba’t ibang sitwasyon. Awtomatikong pinipili ng Git ang angkop na estratehiya, ngunit maaaring itakda ito ng developer nang tahasan sa pamamagitan ng flag --strategy. Ang pag-unawa sa mga estratehiya ay tumutulong sa paghula ng pag-uugali ng Git sa mga kumplikadong pagsasama.

Recursive — ang default na estratehiya para sa pagsasama ng dalawang sangay. Hinahanap ng Git ang karaniwang ninuno, kinakalkula ang mga pagbabago sa bawat sangay, at pinagsasama ang mga ito. Kung natagpuan ang karaniwang ninuno, wastong pinangangasiwaan ng recursive ang pagpapalit ng pangalan ng file at pagdaragdag ng mga bago. Sa mga conflict, maaaring gumamit ang recursive ng mga karagdagang opsyon: ours (awtomatikong pumili ng ating bersyon) at theirs (pumili ng kanilang bersyon).

Octopus — para sa sabay na pagsasama ng higit sa dalawang sangay: git merge feature1 feature2 feature3. Hindi sinusuportahan ng Octopus ang paglutas ng conflict — lahat ng conflict ay dapat lutasin bago tawagin ang utos. Bihirang ginagamit, pangunahin para sa pagsasama ng ilang independiyenteng sangay na garantisadong hindi magkakasalungat (hal. iba’t ibang module).

Ours — isang espesyal na estratehiya na ganap na binabalewala ang mga pagbabago mula sa pinagsamang sangay at pinapanatili ang kasalukuyang nilalaman ng target na sangay. Ang merge-commit ay nilikha, ngunit ang nilalaman ay nananatiling hindi nagbabago. Kapaki-pakinabang kapag kailangan mong itala sa kasaysayan ang katotohanan ng pagsasama ngunit praktikal na tanggihan ang lahat ng pagbabago mula sa ibang sangay.

Paglutas ng mga merge-conflict

Ang merge-conflict ay nangyayari kapag ang parehong mga linya ng isang file ay binago nang magkaiba sa parehong sangay. Hindi matukoy ng Git nang awtomatiko kung aling bersyon ang tama at pinahinto ang merge. Ang conflict ay maaari ring mangyari sa pagpapalit ng pangalan ng file sa isang sangay at pagbabago nito sa isa pa, o sa sabay na pagtanggal at pagbabago ng parehong file.

Proseso ng paglutas: Minamarkahan ng Git ang mga file na may conflict ng mga marker. Sa file ay lumilitaw ang mga bahagi na may <<<<<<< HEAD (ating bersyon), ======= (paghihiwalay) at >>>>>>> feature (kanilang bersyon). Manu-manong inaayos ng developer ang bahaging may conflict, pinipili ang mga kinakailangang linya mula sa parehong bersyon, tinatanggal ang mga marker, ini-save ang file, at idinaragdag ito sa index sa pamamagitan ng git add.

Para sa visual na paglutas ng conflict, sinusuportahan ng Git ang mergetool — isang panlabas na tool sa paghahambing. Mga sikat na mergetool: Meld, KDiff3, Beyond Compare, VS Code(built-in na editor ng conflict). Ipinapakita ng Mergetool ang tatlong panel: ating bersyon, kanilang bersyon, at resulta. Biswal na pinipili ng developer ang mga block ng code para isama sa panghuling file.

# Simulan ang merge at tuklasin ang conflict
git merge feature
# CONFLICT (nilalaman): Merge conflict sa src/main.swift

# Suriin ang mga file na may conflict
git status

# Buksan ang visual na mergetool
git mergetool

# Pagkatapos ng paglutas — idagdag at i-commit
git add src/main.swift
git commit

# Kanselahin ang merge
git merge --abort

Kailan pumili ng merge sa halip na rebase

Ang merge ay mas gusto kaysa rebase sa ilang pangunahing sitwasyon. Una: kapag nagtatrabaho sa mga pampublikong sangay na naa-access ng ibang mga developer. Hindi binabago ng merge ang kasaysayan, at ang mga kasamahan ay maaaring mag-sync nang ligtas. Ang rebase sa isang pampublikong sangay ay lilikha ng divergent na kasaysayan at mga conflict para sa lahat ng nakatanggap na ng mga lumang commit.

Ikalawang sitwasyon: kapag tinatapos ang feature na sangay. Mas gusto ng karamihan sa mga team ang merge (may flag --no-ff) sa main upang itala ang sandali ng integrasyon ng feature. Pinapasimple nito ang pag-navigate sa kasaysayan at pinapayagan ang madaling pagbalik ng buong feature sa pamamagitan ng isang git revert ng merge-commit. Nag-aalok ang GitHub Flow ng tatlong opsyon sa merge: simpleng merge, squash merge, at rebase merge.

Ikatlong sitwasyon: kapag nagtatrabaho sa pull request na dumaan sa review. Nag-aalok ang GitHub at GitLab ng merge button na may iba’t ibang opsyon. Merge (Create a merge commit) — kumpletong kasaysayan na may merge-commit. Squash and merge — malinis na kasaysayan walang detalye ng pag-develop. Rebase and merge — linear na kasaysayan walang merge-commit, ngunit may pagbabago ng mga commit. Ang pagpili ay depende sa mga patakaran ng team.

• Mga pampublikong sangay (main, develop) — merge lang, huwag kailanman rebase.
• Pagtatapos ng PR — merge na may --no-ff para itala ang sandali ng integrasyon.
• Mga sangay na may commit ng iba — hindi binabago ng merge ang trabaho ng iba.
• Bago ang release — mas ligtas ang merge dahil may mas kaunting panganib.
• Pinagsamang sangay — kung maraming developer ang nagtatrabaho sa sangay, sapilitan ang merge.

Pinakamahusay na kasanayan sa pagsasama ng sangay

Unang tuntunin: laging nasa napapanahong bersyon ng target na sangay bago mag-merge. Isagawa ang git checkout main && git pull bago pagsamahin ang feature. Pinapaliit nito ang mga conflict at ginagarantiyang ang merge-commit ay maglalaman ng lahat ng napapanahong pagbabago. Kung ang target na sangay ay malayo na ang narating, isagawa muna ang git merge main sa loob ng feature na sangay upang malutas ang mga conflict sa konteksto nito.

Ikalawang tuntunin: subukan ang code pagkatapos ng merge. Maaaring baguhin ng merge ang pag-uugali, kahit na walang conflict. Ang CI/CD pipeline ay dapat magpatakbo ng mga test sa merge-commit bago ipadala sa produksyon. Ang ilang team ay gumagamit ng merge gates — mga sapilitang pagsusuri na humaharang sa merge hanggang sa makapasa.

Ikatlong tuntunin: idokumento ang mga merge-commit. Ang standard na mensahe “Merge branch ’feature’ into main” ay hindi gaanong kapaki-pakinabang. Inirerekomenda na magdagdag ng paglalarawan ng kung ano ang pinagsama: “Merge authentication module: login, registration, password recovery”. Pinapasimple nito ang pagsusuri ng kasaysayan at paghahanap ng mga regression. Sa malalaking proyekto, ang mga merge-commit ay awtomatikong nabubuo mula sa pangalan ng PR.

• Pagiging napapanahon — bago mag-merge, tiyaking na-update ang target na sangay (git pull).
• Pagsubok — dapat magpatakbo ng mga test ang CI/CD sa resultang merge-commit.
• Mga mapaglarawang mensahe — isaad sa merge-commit kung aling feature ang pinagsama.
• Dalas — pagsamahin ang mga feature na sangay nang maaga at madalas hangga't maaari (maximum isang linggo).
• Pagkansela — ang git revert ng merge-commit ay nagbabalik ng buong feature nang buo.