Pull request sa Git: ano ito at paano gumawa ng PR sa GitHub

Ang pull request (PR) ay mungkahing isama ang mga pagbabago mula sa isang branch papunta sa iba, na ginagawa sa isang platform gaya ng GitHub. Ipinapadala mo ang branch sa server, bubuksan ang PR, sinusuri ng team ang diff, nagkokomento sa mga linya, nagpapatakbo ng mga awtomatikong check, at saka lamang pinipindot ang button ng merge. Sa GitLab, tinatawag na merge request (MR) ang parehong mekanismo. Sa madaling sabi, ang pull request ay checkpoint sa pagitan ng «nagsulat ako ng code» at «nasa main na ang code».

Ano ang git pull request at saan galing ang pangalan

Lumitaw ang pangalan dahil sa kasaysayan. Hinihiling ng may-akda ng mga pagbabago sa may-ari ng repository na «i-pull» ang kanyang branch papunta sa repository ng may-ari — kaya pull request. Nagpasya ang GitLab na pangalanan ito ayon sa resulta — merge request, ibig sabihin kahilingan na mag-merge. Gumagamit ang Bitbucket at Azure DevOps ng terminong «pull request». Sa esensya, iisa ang mga ito: source branch, target branch, paglalarawan, talakayan, check, at button ng merge.

Mahalagang maintindihan na hindi bahagi ng Git ang pull request. Walang bagay na tinatawag na «PR» sa Git mismo; hindi mo ito magagawa sa pamamagitan ng commit o mahahanap sa folder na .git. Ito ay bagay ng platform: iniimbak ng GitHub ang paglalarawan, mga komento, at status ng mga check sa sarili nitong server, habang ang Git ang namamahala lamang sa mga branch at commit na nasa loob ng PR.

Sa usapan ng mga developer, halos palaging ang ibig sabihin ng PR ay pull request: «ipadala mo ang PR», «nasa review na ang PR», «na-merge ko na ang PR». Sa GitLab, sinasabi nilang MR.

Pull request at git pull: ano ang pagkakaiba

Madalas itong malito dahil magkakahawig ang mga salita. Dinadownload ng command na git pull ang mga bagong commit mula sa remote repository at agad na isinasama ang mga ito sa kasalukuyan mong branch — lokal itong operasyon sa terminal. Ang pull request naman ay web page sa GitHub na may mungkahing i-merge ang isang branch sa iba.

Walang hiwalay na command na «git pull request» sa Git. May lumang utility na git request-pull, pero bumubuo lamang ito ng teksto ng e-mail na may buod ng mga pagbabago para ipadala, at walang kinalaman sa mga PR sa GitHub.

Bakit kailangan ang pull request

Habang iisang tao ang gumagawa ng proyekto, maaari kang mag-commit nang direkta sa main. Kapag dalawa o higit pa ang tao sa repository, ang direktang push sa pangunahing branch ay nagiging sanhi ng sirang build at nawalang trabaho. Nilulutas ng pull request ang ilang problema nang sabay:

• code review — nakikita ng pangalawang tao ang mga pagbabago bago pa pumasok sa main, at nahuhuli ang mga error na nalampasan ng may-akda;
• awtomatikong check — pinapatakbo ng GitHub Actions o ibang CI ang mga test at linter sa bawat PR, at pinipigilan ng pulang status ang pag-merge ng sirang code;
• kasaysayan ng mga desisyon — pagkalipas ng isang taon, sa PR mauunawaan mo hindi lang kung ano ang binago kundi kung bakit, kasama ang talakayan;
• pag-ambag sa ibang proyekto — sa open source ay walang write access ka, at ang PR mula sa fork ang tanging paraan para magmungkahi ng pag-aayos;
• proteksyon ng branch — maaaring ipagbawal ng mga branch protection rule ng GitHub ang direktang push sa main at mangailangan ng naaprubahang PR.

Paano gumawa ng pull request sa GitHub mula sa branch

Ito ang pangunahing senaryo para sa team na may write access ang lahat sa repository. Sa feature branch ang trabaho, at sa PR lamang nagbabago ang main.

Hakbang 1. Gumawa ng branch mula sa pinakabagong main

git switch main
git pull
git switch -c feature/login-form

Gawing malinaw ang pangalan ng branch: feature/…, fix/…, o numero ng task. Agad na malalaman ng reviewer kung ano ang pinag-uusapan.

Hakbang 2. Mag-commit

git add src/login.js
git commit -m "Idagdag ang login form"

Isang task, isang PR. Mabilis at maingat na nasusuri ang maliit na PR na 100–300 linya, pero ang PR na 3000 linya ay inaaprubahan ng reviewer nang hindi tinitingnan.

Hakbang 3. Ipadala ang branch sa server (git push para sa pull request)

git push -u origin feature/login-form

Ikinakabit ng flag na -u ang lokal na branch sa remote na branch, at pagkatapos nito sapat na ang simpleng git push. Sa output, kusang magbibigay ang GitHub ng link para gumawa ng PR:

remote: Create a pull request for 'feature/login-form' on GitHub by visiting:
remote:      https://github.com/team/app/pull/new/feature/login-form

Hakbang 4. Buksan ang PR sa web interface

Pumunta sa link mula sa terminal, o buksan ang repository sa GitHub — pagkatapos ng bagong push, may lalabas na banner na may button na «Compare & pull request». Isa pang daan ay ang tab na «Pull requests» at ang button na «New pull request».

1. Tingnan ang pares ng branch: base — saan ito pagsasamahin (karaniwang main), compare — ang iyong branch.
2. Isulat ang title: ano ang nagawa, sa anyong utos o maikling paglalarawan.
3. Sa description, ipaliwanag kung bakit, paano i-check, at ano ang hindi kasama. Kung may template ng PR ang repository, awtomatikong mapupunan ang mga field.
4. Sa kanan, magtalaga ng mga reviewer (Reviewers), assignee, at label kung gamit ng team ang mga ito.
5. I-click ang «Create pull request» o piliin ang draft (tatalakayin sa ibaba).

Paggawa ng PR mula sa terminal: GitHub CLI

Kung ayaw mong lumipat sa browser, may opisyal na utility na gh. Hindi ito command ng Git kundi programa ng GitHub, pero napakagamit nito para sa PR:

gh pr create --base main --title "Idagdag ang login form" --body "Closes #42"
gh pr list
gh pr checkout 57
gh pr merge 57 --squash

Sa tanong na «mga command ng git pull request», ito ang tapat na sagot: kayang gawin ng Git ang mga branch, commit, at push, pero ang PR mismo ay ginagawa sa platform — sa browser, sa pamamagitan ng gh, o sa API.

Paano magpadala ng pull request sa repository ng iba sa pamamagitan ng fork

Sa mga open project, wala kang write access. Kaya una kang gagawa ng fork — sarili mong kopya ng repository sa GitHub — gagawa ka doon, saka mo imumungkahi ang mga pagbabago sa orihinal na proyekto.

1. Sa pahina ng proyekto, i-click ang «Fork» — lalabas ang github.com/you/project.
2. I-clone ang iyong fork at idagdag ang orihinal bilang pangalawang remote, karaniwang tinatawag na upstream.
3. Gumawa ng branch, mag-commit, at ipadala ang branch sa iyong fork.
4. Sa GitHub, buksan ang PR: base repository — ang orihinal na proyekto, head repository — ang iyong fork at branch.

git clone git@github.com:you/project.git
cd project
git remote add upstream https://github.com/owner/project.git
git switch -c fix/typo-readme
git commit -am "Itama ang typo sa README"
git push -u origin fix/typo-readme

Bago magsimula, tingnan ang file na CONTRIBUTING.md: karaniwang nakalagay doon ang mga patakaran sa pag-format ng commit, test, at kung kailangan munang gumawa ng issue. Panatilihing bago ang iyong fork: git fetch upstream at git rebase upstream/main sa iyong branch, para hindi mahuli ang PR sa orihinal.

Merge request sa GitLab: ano ito at paano gumawa

Ang merge request ng GitLab ay katumbas mismo ng pull request ng GitHub. Magkaiba ang pangalan at detalye ng interface, pero pareho ang proseso: branch, push, kahilingan na mag-merge, review, merge.

Maaari kang gumawa ng MR sa ilang paraan:

• sa pamamagitan ng link na inilalabas ng GitLab sa terminal pagkatapos ng git push ng bagong branch;
• sa seksyong Merge requests ng proyekto, gamit ang button na «New merge request», pagpili ng source at target na branch;
• mismo sa push, gamit ang push options ng GitLab — nang hindi pumupunta sa browser.

git push -o merge_request.create -o merge_request.target=main origin feature/login-form

Bahagyang magkaiba ang terminolohiya ng GitLab: ang pag-apruba ay tinatawag na approve, ang taong responsable sa merge ay assignee, at sa halip na GitHub Actions ay GitLab CI/CD na may file na .gitlab-ci.yml. May draft din ang MR — tinatawag itong Draft.

Pag-review ng pull request

Binubuksan ng reviewer ang tab na «Files changed» at nakikita ang diff. Maaari siyang mag-iwan ng komento sa anumang linya o magmungkahi ng handang pagbabago (suggestion), na maaaring i-apply ng may-akda sa isang click. Pinagsasama-sama ang mga komento sa iisang review at ipinapadala kasama ng isa sa mga verdict na ito:

• Comment — mga puna lamang nang walang desisyon;
• Approve — naaprubahan ang mga pagbabago;
• Request changes — kailangan pang ayusin, hindi inirerekomenda ang merge.

Ang mabuting review ay tumitingin sa lohika, kalinawan, mga test, at mga corner case, sa halip na makipagtalo tungkol sa panlasa — ipaubaya ang format sa linter sa CI. Dapat sagutin ng may-akda ang bawat komento: inayos na, napag-usapan na, o iniiwan nang ganoon na may paliwanag.

Paano i-check ang PR ng iba sa sarili mong computer (git checkout pull request)

Minsan kailangang patakbuhin ang code sa sarili mong makina. Kung nasa parehong repository ang branch, sapat na ang git fetch at git switch. Para sa PR mula sa fork, naglalabas ang GitHub ng espesyal na reference na pull/<numero>/head:

git fetch origin pull/57/head:pr-57
git switch pr-57

Sa GitLab, ang katumbas na reference ay merge-requests/<numero>/head. O gamitin lang ang gh pr checkout 57 kung naka-install ang GitHub CLI.

Paano i-update ang pull request pagkatapos ng mga puna

Nakakabit ang PR sa branch, hindi sa partikular na mga commit. Sapat na ang paggawa ng mga bagong commit sa parehong branch at pag-push nito — awtomatikong magsa-update ang PR, at hindi na kailangang gumawa ng bagong kahilingan.

git commit -am "Tugunan ang mga puna sa review"
git push

Git rebase pull request: kunin ang pinakabagong main

Habang nasa review ang PR, umuusad ang main. Kapag sinabi ng GitHub na luma na ang branch o may conflict, i-update ito. Ang paraan gamit ang rebase ay nagbibigay ng tuwid na kasaysayan:

git fetch origin
git rebase origin/main
# lutasin ang mga conflict, git add, git rebase --continue
git push --force-with-lease

Pagkatapos ng rebase, nagbabago ang mga hash ng commit, kaya hindi tatanggapin ang normal na push — kailangan ang puwersadong push. Gamitin ang --force-with-lease: tatanggi itong mag-overwrite kung may dumating na commit ng iba sa branch. Kung hindi ikaw lang ang nagtatrabaho sa branch, mas ligtas na i-merge ang main gamit ang git merge origin/main — hindi nito binabago ang kasaysayan.

Paano i-merge ang pull request: merge, squash, at rebase

Kapag naaprubahan ang review at berde ang mga check, maaari nang i-merge ang PR. Nag-aalok ang GitHub ng tatlong paraan, at maaaring payagan ng administrator ng repository ang ilan lamang sa mga ito.

Ang pag-merge ng pull request sa interface ay esensyal na parehong git merge, pero ginagawa sa server. Pagkatapos ng merge, magmumungkahi ang GitHub na burahin ang branch — sumang-ayon, dahil hindi na ito kailangan. Linisin din ang iyong computer:

git switch main
git pull
git branch -d feature/login-form

Maaari ring i-merge ang PR nang manu-mano mula sa terminal: i-merge ang branch sa main sa lokal na computer at i-push. Matutukoy ng GitHub na nasa base na ang mga commit ng branch at ima-mark nito ang PR bilang merged. Pero nawawala ang mga check at ang mga patakaran sa proteksyon ng branch sa paraang ito, kaya karaniwang gumagamit ng button ang mga team.

Auto-merge at merge queue

Kapag matagal ang mga check, maaari mong i-on ang auto-merge: awtomatikong magme-merge ang PR kapag natugunan na ang lahat ng kondisyon. Sa malalaking repository, ginagamit ang merge queue, na nagche-check ng PR sa ibabaw ng mga nasa pila, para hindi masira ang main dahil sa mga hindi magkatugmang pagbabago.

Mga draft na pull request (Draft)

Ang draft ay PR na hindi pa handa para sa review. Hindi ito maaaring i-merge, at hindi nakakatanggap ng kahilingan para sa review ang mga reviewer. Kapaki-pakinabang ang mga draft para maagang maipakita ang direksyon, mapatakbo ang CI, o makakuha ng opinyon tungkol sa arkitektura. Sa GitHub, kapag gumagawa ng PR, piliin ang opsiyon ng draft sa dropdown ng button ng paglikha, o gamitin ang gh pr create --draft. Kapag tapos na ang trabaho, i-click ang «Ready for review». Sa GitLab, minamarkahan ang draft ng prefix na Draft: sa title ng MR.

Pag-uugnay ng pull request sa issues

Kung isusulat mo sa description ng PR ang keyword at numero ng task, awtomatikong isasara ng GitHub ang issue pagkatapos ng merge sa default na branch:

Closes #42
Fixes #17
Resolves #8

Gumagana ang mga salitang close, fix, at resolve sa iba't ibang anyo (closes, fixed, resolves). Ang pagbanggit lamang ng #42 nang walang keyword ay gumagawa ng link, pero hindi nito isinasara ang task. Ganito rin sa GitLab ang Closes #42 at mga katulad na parirala.

Maaari bang burahin ang pull request o merge request

Hindi kayang burahin ng ordinaryong miyembro ang PR sa GitHub — maaari lamang itong isara gamit ang button na «Close pull request». Nananatili sa kasaysayan ang nakasarang PR, at maaari itong buksang muli. Burahin nang hiwalay ang branch pagkatapos isara. Ang tuluyang pagbura ng PR ay posible lamang sa pamamagitan ng suporta ng GitHub, halimbawa kung may napasok na secret dito.

Sa GitLab, maaaring isara ang MR ng may-akda o ng miyembro na may karapatan, at burahin ito ng may-ari ng proyekto o administrator. Kung may password o token na napasok sa PR, hindi sapat ang pagsara: bawiin agad ang secret, dahil nasa server na ang mga commit.

Mga karaniwang pagkakamali sa pull request

• PR mula sa main. Nag-commit ka sa sarili mong main at nagbukas ng PR mula roon. Ang susunod na PR ay maglalaman din ng mga lumang pagbabago. Laging magtrabaho sa hiwalay na branch.
• Maling base branch. Binuksan ang PR sa develop sa halip na main, o kabaligtaran. Maaaring palitan ang base gamit ang button na Edit sa tabi ng title ng PR.
• May mga hindi kailangang file sa diff. Mga build, node_modules, .env. Idagdag ang mga ito sa .gitignore at alisin sa index gamit ang git rm --cached.
• Napakalaking PR. Hatiin ang task sa ilang magkakasunod na PR.
• Normal na push pagkatapos ng rebase. Error na rejected (non-fast-forward). Gamitin ang git push --force-with-lease, hindi ang --force.
• Mga conflict. Huwag itong lutasin nang nakapikit sa web editor — i-pull ang main sa lokal, lutasin, at subukan ang mga test.

Pull request sa git flow at iba pang proseso

Angkop ang pull request sa anumang proseso ng team. Sa GitHub Flow, simple lang: branch mula sa main, PR, review, merge, deploy. Sa git flow, binubuksan ang mga PR sa develop mula sa mga feature branch, at dumadaan din sa PR papuntang main ang mga release at hotfix branch. Sa trunk-based development, maikli ang mga PR at nabubuhay nang ilang oras, hindi araw. Anuman ang proseso, iisa ang tuntunin: ang mga pagbabago sa mga shared na branch ay dumadaan lamang sa pull request.

Buod

Ang pull request ay mekanismo ng platform, hindi command ng Git: branch na ipinadala sa server, kasama ang pahina para sa talakayan, review, at mga check. Sa GitLab ito ay merge request; sa usapan, PR at MR ang tawag. Gumawa ng PR mula sa hiwalay na branch, panatilihin itong maliit, i-update sa pamamagitan ng pag-push sa parehong branch, at piliin ang paraan ng merge na tugma sa kasaysayan ng proyekto. Ang feature branch, fork, at pull request ay detalyadong tinalakay nang praktikal sa kurso sa Git.