Pagsasama ng mga branch — ano ito, mga paraan ng pagsasama at pagresolba ng conflicts

Ano ang merge sa Git

Ang merge sa Git — ay ang operasyon ng pagsasama ng dalawa o higit pang kasaysayan ng pag-develop sa iisa. Kapag ang isang developer ay nag-merge ng branch, awtomatikong hinahanap ng Git ang karaniwang ninuno (base commit) at lumilikha ng bagong merge commit na naglalaman ng mga pagbabago mula sa parehong branch. Three-way merge — ang karaniwang algorithm na nagkukumpara ng tatlong estado: ang karaniwang ninuno, unang branch, at pangalawang branch.

Ang proseso ng merge ay nagsisimula sa command na git merge. Tinutukoy ng Git ang punto ng pagkakahiwalay ng mga branch at sunud-sunod na inilalapat ang mga pagbabago mula sa source branch patungo sa target branch. Kung ang mga pagbabago ay hindi magkasalungat, ang Git ay nagsasagawa ng fast-forward o lumilikha ng merge commit depende sa mga setting. Fast-forward — ang senaryo kung saan ang target branch ay inililipat lamang sa mga commit ng source branch.

# Lumipat sa target branch at pagsamahin
git checkout main
git merge feature/payment-module

# Pagsamahin gamit ang explicit no-fast-forward
git merge --no-ff feature/payment-module

# I-abort ang merge kung masyadong kumplikado ang conflicts
git merge --abort

Ang flag na --no-ff (no fast-forward) ay pumipilit na gumawa ng merge commit kahit na posible ang fast-forward. Ito ay nagpapanatili ng impormasyon na ang mga pagbabago ay ginawa sa isang hiwalay na branch. Maraming team ang mas pinipili ang pamamaraang ito upang mapanatili ang pagsasanga ng kasaysayan sa isang tahasang anyo.

Mga paraan ng pagsasama ng branch

Sa Git mayroong tatlong pangunahing estratehiya ng pagsasama ng branch, bawat isa ay angkop para sa isang partikular na senaryo. Ang pagpili ng estratehiya ay nakadepende sa kultura ng team at sa mga kinakailangan para sa kalinisan ng kasaysayan ng proyekto.

Ang Standard merge ay lumilikha ng merge commit na may dalawang magulang. Ang buong kasaysayan ay pinapanatili, ngunit ang grap ng pagsasanga ay nagiging mas kumplikado. Squash merge ay pinagsasama ang lahat ng commit ng feature branch sa isa at inilalapat ito sa target branch — ang kasaysayan ay nagiging linear at malinis, ngunit nawawala ang impormasyon tungkol sa mga intermediate na yugto.

Ang Rebase, kahit na hindi isang ganap na merge, ay nakakamit ang parehong resulta — ang mga pagbabago mula sa isang branch ay inililipat sa isa pa. Ang pagkakaiba ay ang kasaysayan ay muling isinusulat: ang mga commit ng feature branch ay muling nililikha sa ibabaw ng huling commit ng target branch. Ito ay nagbibigay ng perpektong linear na kasaysayan, ngunit nangangailangan ng force push kapag nagpapadala.

Paano magresolba ng conflicts sa merge

Ang conflict sa merge ay nangyayari kapag sa dalawang branch ay binago ang parehong mga linya ng isang file. Hindi awtomatikong matutukoy ng Git kung aling bersyon ang pananatilihin at nangangailangan ng interbensyon ng developer. Ang mga conflict ay ipinapakita sa mga file bilang mga espesyal na marker: <<<<<<<, =======, >>>>>>>.

Ang proseso ng pagresolba ng conflict ay may kasamang ilang hakbang. Una, bubuksan ng developer ang conflict na file at manu-manong pipiliin ang mga kinakailangang pagbabago. Mahalaga na hindi lamang pumili ng isa sa mga bersyon, kundi maunawaan ang lohika ng parehong pagbabago at gumawa ng tamang desisyon. Pagkatapos i-edit ang file, ang mga conflict marker ay aalisin at ang mga pagbabago ay idaragdag sa staging area sa pamamagitan ng git add.

# Tingnan ang listahan ng conflict na file
git status

# Simulan ang mergetool (hal. VS Code, IntelliJ)
git mergetool

# Pagkatapos malutas ang lahat ng conflicts
git add .
git merge --continue

# O i-abort nang buo ang merge
git merge --abort

Ang paggamit ng visual merge tools ay makabuluhang nagpapabilis ng pagresolba ng conflict. Ang VS Code, IntelliJ IDEA at GitKraken ay nagbibigay ng mga interface na may tatlong panel: kasalukuyang branch, papasok na branch, at resulta. Ang tool na git mergetool ay awtomatikong nagbubukas ng naka-configure na editor para sa bawat conflict na file.

Ang pinakamahusay na paraan upang maiwasan ang mga kumplikadong conflict ay regular na pag-sync ng feature branch sa pangunahing branch. Kung ang developer ay nagme-merge ng main sa kanyang branch isang beses sa isang araw, ang mga conflict ay magiging maliit at madaling malutas. Ang pag-iipon ng mga pagbabago sa loob ng isang linggo ay ginagarantiyahan ang mga kumplikadong conflict na may mataas na panganib ng mga pagkakamali.

Kailan gumamit ng rebase sa halip na merge

Ang Rebase at merge — dalawang paraan ng pagsasama ng mga pagbabago, at ang pagpili sa pagitan ng mga ito ay madalas na nagdudulot ng debate sa mga team. Inililipat ng Rebase ang mga commit mula sa isang branch patungo sa isa pa, na muling isinusulat ang kasaysayan. Ang Merge ay lumilikha ng bagong merge commit, na pinapanatili ang kasaysayan ng pagsasanga. Ang bawat pamamaraan ay may mga pakinabang at limitasyon nito.

Ang Rebase ay angkop kapag ang developer ay nagtatrabaho sa kanyang lokal na feature branch at nais na makakuha ng malinis na linear na kasaysayan bago gumawa ng Pull Request. Pagkatapos ng rebase, ang lahat ng commit ay sunud-sunod na nakaayos, nang walang mga hindi kinakailangang merge commit. Gayunpaman, ang rebase ay nangangailangan ng force push at hindi mailalapat sa mga branch na pinagtatrabahuhan ng maraming tao nang sabay-sabay.

• Rebase — para sa personal na feature branch kung saan kailangan ang malinis na kasaysayan
• Merge — para sa magkasanib na branch at pagtatala ng sandali ng pagsasama
• Squash — kapag ang feature branch ay naglalaman ng maraming maliliit na working commit

Ang gintong patakaran ng Git: huwag gumamit ng rebase sa mga commit na naipadala na sa shared repository. Ito ay ginagarantiyahan na ang kasaysayan sa shared branch ay mananatiling hindi nababago, at ang ibang mga developer ay hindi makakatagpo ng mga duplicate o nawawalang commit. Para sa pagsasama ng feature branch sa pangunahing branch, gumamit ng merge sa pamamagitan ng Pull Request.

Pinakamahuhusay na kasanayan sa pagsasama ng branch

Ang tamang proseso ng merge — ang pundasyon ng matatag na pag-develop. Sa modernong pagtutulungan ng team, ang merge ay isinasagawa hindi sa pamamagitan ng console, kundi sa pamamagitan ng Pull Request sa GitHub o Merge Request sa GitLab. Ang PR ay dumadaan sa code review, awtomatikong CI checks, at pagkatapos lamang ay isasama sa pangunahing branch.

Unang kasanayan — mag-merge lamang pagkatapos makapasa sa lahat ng checks. Ang CI pipeline ay dapat bumuo ng proyekto, magpatakbo ng mga test, at suriin ang kalidad ng code. Kung kahit isang check ay hindi pumasa, ang merge ay haharangin. Ang mga modernong platform (GitHub, GitLab) ay may built-in na proteksyon: ang branch protection rules ay awtomatikong humaharang ng merge kapag bumagsak ang CI.

Pangalawang kasanayan — huwag kailanman mag-merge ng sirang code. Bago ang merge, dapat tiyakin ng developer na ang kanyang mga pagbabago ay hindi sumisira sa build at hindi nagre-regress ng umiiral na functionality. Para dito mayroong mga automated test at code review.

Pangatlong kasanayan — linisin ang mga feature branch pagkatapos ng merge. Ang branch na na-merge na ay dapat tanggalin. Ito ay pumipigil sa kalituhan at pagkalat ng repository. Awtomatikong nag-aalok ang GitHub na tanggalin ang branch pagkatapos ng merge ng PR, at ang mga setting ng repository ay maaaring i-configure para sa awtomatikong pagtanggal.