Aprubahan / Sumang-ayon: ano ito, approval at code review sa Git

Ano ang aprub ng pull request

Aprub (approval) — ay isang positibong review sa pull request, na nangangahulugang sinuri ng reviewer ang code, walang nakitang kritikal na problema at itinuturing na handa na ang mga pagbabago para pagsamahin. Sa interface ng GitHub, ito ang berdeng buton na «Approve» sa pahina ng PR. Pagkatapos ng aprub, ang may-akda (o sinumang kalahok na may karapatang sumulat) ay maaaring magsagawa ng merge.

Ang proseso ng aprub ay bahagi ng Branch Protection Rules. Ang mga may-ari ng repository ay nagko-configure ng mga mandatoryong kinakailangan: minimum na bilang ng mga aprub (hal. 1 o 2), kung sino ang maaaring mag-apruba (mga may-ari ng code, miyembro ng team), at kung ang PR ay kailangang aprubahan muli pagkatapos ng mga pagbabago (Dismiss stale reviews). Kung hindi na-configure ang mga patakaran, ang aprub ay isang opsyonal na hakbang, ngunit sa mga propesyonal na team ito ay sapilitan.

Ang GitLab ay gumagamit ng katulad na mekanismo na tinatawag na Approval Rules. Sa GitLab, maaari mong i-configure kung gaano karaming aprub ang kinakailangan mula sa iba’t ibang grupo (hal. 2 mula sa backend developer at 1 mula sa DevOps). Pagkatapos matanggap ang lahat ng mandatoryong aprub, ang PR ay awtomatikong ina-unblock para sa merge sa kondisyon na berde ang CI/CD pipeline.

Mga uri ng review: Approve, Request Changes, Comment

Sa GitHub at GitLab mayroong tatlong uri ng review na maaaring iwan ng reviewer sa isang pull request. Ang bawat uri ay may iba’t ibang status at kahihinatnan para sa proseso ng pagsasama. Approve — berde, Request Changes — pula, Comment — neutral na kulay abo. Ang pagpili ng uri ay depende sa kalidad ng code at kahandaan ng mga pagbabago para sa pagtanggap.

Approve — kinumpirma ng reviewer: ang code ay naisulat nang tama, sumusunod sa mga pamantayan, walang halatang error, at maaaring pagsamahin. Ang Approve ay hindi nangangahulugan na ang code ay perpekto — lamang na ito ay sapat na mabuti para sa produksyon. Kung may mga maliliit na puna (estilo, pagpapangalan), maaaring iwan ang mga ito bilang komento nang hindi binablock ang PR.

Request Changes — ang reviewer ay nakakahanap ng mga problemang dapat ayusin bago ang merge: mga lohikal na error, mga kahinaan, paglabag sa arkitektura, kawalan ng mga test. Pagkatapos ng Request Changes, ang PR ay naka-block, at para ma-unblock ay kinakailangan ang muling aprub mula sa parehong reviewer (kung ang opsyon na Dismiss stale reviews ay naka-on para sa mga bagong commit).

• Approve — handa na ang code para sa pagsasama, maaaring i-merge pagkatapos makaraan ang CI.
• Request Changes — mandatoryong pag-aayos, naka-block ang PR hanggang sa muling review.
• Comment — pangkalahatang puna o mungkahi nang hindi binablock ang PR.

Pag-configure ng mga patakaran ng aprub sa repository

Branch Protection Rules — ay ang mekanismo ng GitHub para sa kontrol ng kalidad ng pagsasama. Nako-configure sa Settings → Branches para sa bawat protektadong branch (main, develop, release/*). Mga pangunahing parameter: bilang ng mga mandatoryong aprub, mga may-ari ng code (CODEOWNERS), mandatoryong pagsusuri ng CI/CD, at pagbabawal ng push nang walang PR.

Ang parameter na Dismiss stale pull request approvals — awtomatikong nag-aalis ng mga aprub kung may bagong commit na idinagdag sa PR. Tinitiyak nito na inaaprubahan ng mga reviewer ang eksaktong bersyon ng code na isasama. Kung wala ang setting na ito, ang may-akda ay maaaring magdagdag ng bagong code pagkatapos ng aprub at ito ay mapupunta sa main nang walang muling pagsusuri.

CODEOWNERS — isang file sa root ng repository na nagtatalaga ng mga responsableng tao para sa iba’t ibang direktoryo. Kung ang PR ay humipo sa mga file na pagmamay-ari ng isang may-ari ng code, ang kanyang aprub ay nagiging mandatoryo. Ang CODEOWNERS ay naghahati ng mga zone ng responsibilidad: developer ng iOS ay responsable para sa mga Swift file, DevOps — para sa mga configuration ng Docker, mga tester — para sa mga test scenario.

# Halimbawang CODEOWNERS file sa root ng repo

# Ang mga iOS developer ay nagmamay-ari ng Swift code
*.swift @team/ios-developers

# Ang DevOps ay nagmamay-ari ng configuration ng CI/CD
.github/workflows/* @devops-team

# Sinusuri ng mga QA engineer ang mga test
**/tests/* @qa-engineers

# Mga default na may-ari para sa lahat ng iba pa
* @tech-leads

Code review bago ang aprub: ano ang susuriin

Code review bago ang aprub — ay isang sistematikong pagsusuri ng code, hindi isang mababaw na pagtingin sa diff. Ang isang de-kalidad na code review ay sumasaklaw sa pagsusuri ng arkitektura, lohika, estilo, mga test, at seguridad. Kung wala ang pagsusuring ito, ang aprub ay nagiging pormalidad, hindi isang tool sa pagkontrol ng kalidad.

Ano ang sinusuri muna: lohika ng mga pagbabago — nalulutas ba ng code ang itinakdang gawain, may mga side effect ba, tama ba ang paghawak sa mga boundary case. Mga test — saklaw ba ng mga bagong test ang lahat ng senaryo, pumapasa ba ang mga kasalukuyang test pagkatapos ng mga pagbabago. Seguridad — mayroon bang SQL injection, XSS, pagtagas ng sensitibong data.

Ano ang hindi dapat maging paksa ng review: estilo ng pag-format (para diyan ay may mga linter at formatter), mga desisyong arkitektural na ginawa nang maaga (napag-uusapan ang mga ito bago sumulat ng code). Kung ang review ay may higit sa 400 linya o tumatagal ng higit sa isang oras — ito ay senyales na ang gawain ay masyadong malaki at nangangailangan ng decomposition. Pinakamahusay na kasanayan ng review — mga bahagi ng 200–400 linya sa loob ng 24 na oras pagkatapos ng paggawa ng PR.

• Lohika — kawastuhan ng solusyon sa gawain, paghawak ng error, mga boundary case.
• Mga test — saklaw ng mga bagong senaryo, pagpasa ng mga umiiral na, kawalan ng mga flaky test.
• Seguridad — kawalan ng injection, pag-escape ng output, pag-access sa data.
• Pagganap — kahusayan ng mga algorithm, labis na query, pagtagas ng memorya.
• Dokumentasyon — na-update ba ang dokumentasyon, naiintindihan ba ang mga komento sa mga kumplikadong bahagi.

Daloy ng trabaho na may aprub sa isang team

Ang karaniwang daloy ng trabaho na may aprub sa isang team na 5–10 developer ay ganito: ang developer ay gumagawa ng PR, nagtatalaga ng mga reviewer (karaniwang 1–2 tao mula sa team o mga may-ari ng code), ang CI/CD ay nagpapatakbo ng mga awtomatikong pagsusuri. Pagkatapos matanggap ang lahat ng mandatoryong aprub at berdeng CI, ang may-akda ay nagsasagawa ng merge. Ang oras mula sa paggawa ng PR hanggang sa merge ay average na 2 oras hanggang 2 araw depende sa pagiging kumplikado.

Ang GitHub Actions ay nagbibigay-daan sa awtomatikong merge pagkatapos ng aprub. Kung ang mga patakaran ng branch ay na-configure, ang GitHub mismo ay nagba-block ng merge hanggang sa matupad ang lahat ng kondisyon. Ang ilang team ay gumagamit ng bors-ng o Mergify — mga bot na awtomatikong nagsasama ng PR pagkatapos matanggap ang lahat ng aprub at makaraan ang CI. Pinapabilis nito ang proseso at inaalis ang human factor sa merge.

Makabagong approach — trunk-based development na may mga panandaliang branch. Sa daloy ng trabahong ito, ang aprub ay dapat makuha sa loob ng ilang oras, kung hindi ang gawain ay itinuturing na luma na at nangangailangan ng muling pag-sync sa main. Ang mga team na may mataas na kultura ng review ay naglalayon sa oras ng aprub na hindi hihigit sa 4 na oras ng trabaho.

Mga pagkakamali sa aprub at kung paano maiiwasan ang mga ito

Pinakakaraniwang pagkakamali — pormal na aprub nang walang tunay na pagsusuri ng code. Kapag malaki ang PR o malapit na ang deadline, maaaring pindutin ng reviewer ang Approve nang hindi sinusuri ang mga pagbabago. Ito ay nagpapababa ng buong proseso ng code review. Solusyon: magtakda ng limitasyon sa laki ng PR (hindi hihigit sa 400 linya) at gumamit ng mga tool sa pagsusuri ng code (SonarQube, CodeClimate) para sa awtomatikong pagsusuri.

Pangalawang pagkakamali — labis na mahigpit na aprub. Ang pag-aasam ng perpektong code ay humaharang sa pag-unlad. Ang mga reviewer kung minsan ay humihiling na ayusin ang mga puna sa estilo na hindi nakakaapekto sa kalidad. Solusyon: malinaw na paghiwalayin ang mga mandatoryong puna (naka-block) at opsyonal na mungkahi (mga komento). Binibigyang-daan ng GitHub na malinaw na ipahiwatig kung ang komento ay naka-block.

Pangatlong pagkakamali — aprub nang walang pagsusuri ng CI/CD. Kahit na mukhang tama ang code, maaaring hindi ito mag-compile o bumagsak sa mga test. Ang naka-configure na Branch Protection ay awtomatikong nagba-block ng merge sa pulang CI, ngunit ang ilang team ay pinapatay ang proteksyong ito para sa bilis. Solusyon: palaging suriin ang status ng CI bago ang aprub at huwag kailanman aprubahan ang PR na may pulang pipeline.

• Pormal na aprub — kawalan ng tunay na pagsusuri ng code. Solusyon: limitasyon ng 400 linya sa PR.
• Labis na kahigpitan — pag-block dahil sa mga puna sa estilo. Solusyon: paghahati sa blocking at optional.
• Pagwawalang-bahala sa CI — aprub na may pulang pipeline. Solusyon: palaging suriin ang status ng mga pagsusuri.
• Pagtalaga ng may-akda — aprub mula sa may-akda ng PR. Solusyon: pag-configure ng Branch Protection laban sa may-akda.