Pull Request

Chapter sebelumnya menyelesaikan sisi teknis model fork: pekerjaan sampai ke fork, pembaruan sampai ke meja kontributor. Yang tersisa adalah bagian paling manusiawi: bagaimana pemilik repository asal menimbang perubahan itu sebelum menerimanya. Jawaban platform modern bernama pull request — permintaan yang menyatukan diff, diskusi, pemeriksaan otomatis, dan keputusan merge dalam satu halaman. Chapter ini membedah anatomi pull request, melatih menyiapkan yang berkualitas, lalu menjalankan sisi Git-nya sungguhan di sandbox.

Pull Request itu Fitur Platform #

Perintah git pull-request tidak ada — dan memang tidak pernah ada di Git inti. Pull request adalah fitur antarmuka web milik platform hosting: GitHub, GitLab (menyebutnya merge request), dan Bitbucket sama-sama memilikinya dengan nama berbeda. Isinya satu konsep: permintaan untuk menggabungkan satu branch ke branch lain, disertai ruang diskusi di sekitar diff-nya.

Dua istilah platform yang perlu dikenal sejak awal. Base adalah branch tujuan — biasanya main. Compare adalah branch sumber — hasil kerja yang diajukan. Satu pull request mengusulkan: “pindahkan isi compare ke base, setelah kita sepakat isinya.”

Anatomi Sebuah Pull Request #

Halaman pull request di platform mana pun memuat lima bagian pokok:

Bagian	Isinya	Perannya
Judul dan deskripsi	ringkasan perubahan, alasan, cara menguji	kontrak pertama reviewer
Diff	perbandingan base…compare per berkas	bahan telaah baris-per-baris
Review comments	komentar menempel pada baris diff	diskusi teknis tempat masalah ditandai
Status checks	hasil build, tes, dan pemeriksaan otomatis	syarat kuantitatif sebelum merge
Tombol merge	eksekusi keputusan (merge, squash, atau rebase)	momen perubahan resmi masuk

Deskripsi dan diff kita kendalikan penuh dari sisi Git — sisanya hidup di platform. Praktik terbaiknya satu kalimat: pull request yang baik sudah menang separuh sebelum dibuka, karena semua bahan telaahnya disiapkan sebelum tombol kirim ditekan.

Menyiapkan Pull Request Berkualitas #

Tiga kebiasaan memisahkan PR yang cepat selesai dari yang menggantung berminggu-minggu:

Satu branch, satu pokok bahasan. Branch fitur/galeri yang diam-diam juga mengganti font dasar akan memaksa reviewer menimbang dua keputusan sekaligus. Pecah kontribusi besar menjadi PR kecil berurutan.
Commit yang bersih dan bercerita. Riwayat branch adalah kerangka deskripsi otomatis; commit “wip” dan “fix lagi” mereduksinya jadi derau. Rapikan dengan interactive rebase sebelum mengirim, dan tulis pesannya serius sejak awal — polanya dirangkum di Menulis Commit Message .
Deskripsi yang menjawab tiga pertanyaan: apa yang berubah, mengapa perlu, dan bagaimana cara mengujinya. Reviewer yang harus menebak salah satu dari tiga itu akan menunda membuka PR tersebut.

Sisi Git-nya: Menyiapkan dan Mengirim Branch #

Semua yang bisa disiapkan dari terminal kita latih di sandbox — skenario model shared: Budi pemilik toko-pr.git, Siti kontributor. Budi meletakkan kerangka:

bash
mkdir budi && cd budi
git init -b main
git config user.name "Budi Santoso"
git config user.email "[email protected]"
printf 'beranda\n' > situs.md
git add situs.md
git commit -m "Buat kerangka toko"
git init --bare ../toko-pr.git
git remote add origin ../toko-pr.git
git push -u origin main

Siti menyalin lalu bekerja di branch khusus — satu pokok bahasan, sesuai kebiasaan di atas:

bash
cd ..
git clone toko-pr.git siti
cd siti
git switch -c fitur/galeri

Output yang Dihasilkan (perintah terakhir):

text

Switched to a new branch 'fitur/galeri'

bash
printf 'galeri\n' > galeri.md
git add galeri.md
git commit -m "Tambah halaman galeri"

Output yang Dihasilkan (perintah terakhir):

text
[fitur/galeri fac24ee] Tambah halaman galeri
 1 file changed, 1 insertion(+)
 create mode 100644 galeri.md

Pengirimannya satu dorong — branch, bukan main:

bash

git push -u origin fitur/galeri

Output yang Dihasilkan:

text
To ../toko-pr.git
 * [new branch]      fitur/galeri -> fitur/galeri
branch 'fitur/galeri' set up to track 'origin/fitur/galeri'.

Baris [new branch] mengumumkan cabang baru di remote, dan set up to track mengikat branch lokal Siti ke origin/fitur/galeri — ikatan push/pull yang dibahas di Tracking Branch . Kondisi remote kini terverifikasi dari mana saja:

bash

git ls-remote origin

Output yang Dihasilkan:

text
c79176686bc4c2bf981c8253d7bf2b1ec3ec67ac        HEAD
fac24ee225fbc7d2d12cea0e32255cce8cab46aa        refs/heads/fitur/galeri
c79176686bc4c2bf981c8253d7bf2b1ec3ec67ac        refs/heads/main

Dua branch di server: main milik Budi di c79176686, dan fitur/galeri milik Siti di fac24ee. Dua hash itulah yang dipegang platform saat menyusun pull request.

Di titik inilah tindakan berpindah ke web: Siti membuka halaman repository, menekan tombol bandingkan-dan-buat-pull-request, lalu mengisi judul, deskripsi, dan tujuan review — base main, compare fitur/galeri. Platform tidak menyalin ulang apa pun: halaman PR tinggal membaca kedua branch yang sudah ada di server, menghitung selisihnya, dan membuka ruang diskusi. Persis dua hal berikut bisa Siti periksa sendiri dari terminal sebelum menekan tombol kirim:

bash

git log --oneline main..fitur/galeri

Output yang Dihasilkan:

text

fac24ee Tambah halaman galeri

bash

git diff main...fitur/galeri

Output yang Dihasilkan:

text
diff --git a/galeri.md b/galeri.md
new file mode 100644
index 0000000..5571b7a
--- /dev/null
+++ b/galeri.md
@@ -0,0 +1 @@
+galeri

main..fitur/galeri menjawab “commit apa saja yang diusulkan” — satu baris, satu commit, tepat seperti PR yang sehat. main...fitur/galeri (tiga titik) menjawab “isinya mengubah apa” — berkas baru galeri.md setinggi satu baris. Hash di mesin pembaca berbeda; pola dua perintah inilah yang juga dipakai reviewer untuk membaca isi PR dari clone masing-masing.

Tiga Strategi Merge di Halaman PR #

Pull request berakhir di satu tombol, tetapi platform menawarkan tiga cara menekannya — dan ketiganya meninggalkan jejak riwayat yang berbeda di main:

Strategi	Apa yang masuk ke main	Bentuk riwayat
Merge	commit merge berinduk dua + semua commit branch	gelembung merge, riwayat cabang utuh
Squash	satu commit baru gabungan seluruh branch	linear, riwayat cabang lenyap
Rebase	commit branch ditanam ulang di ujung main	linear, commit asli (dengan hash baru)

Merge menjaga konteks kerja — reviewer bisa menelusuri kapan diskusi per commit terjadi — dengan bayaran gelembung merge di graf. Squash memberi riwayat main paling ramping: PR yang 15 commit kotor menjadi satu commit “Tambah halaman galeri (#12)”; konsekuensinya, kerangka pengerjaan di dalam branch hilang dan tanggal penulis commit gabungan ditimpa. Rebase menawari linear tanpa menggabungkan — tiap commit tetap berdiri sendiri, hanya berpindah dasar; komprominya, hash berubah seperti semua penulisan-ulang riwayat. Dampak terperinci ketiganya diuraikan platform di dokumentasi strategi merge pull request , dan mekanisme di baliknya sudah kita kuasai: semuanya adalah variasi dari git merge dan fast-forward vs merge commit yang dilatih di section Branch dan Merging.

Setelah tombol ditekan, platform juga menawarkan menghapus branch compare — tugas yang di Git murni berupa git push origin --delete, dibedah di Menghapus Remote Branch . Panduan lengkap fitur PR dari sudut pandang platform bisa dibaca di dokumentasi pull request GitHub .

Tombol merge, status checks, dan deskripsi yang baik hanyalah panggungnya. Pertunjukan sebenarnya ada di ruang review: siapa membaca apa, bagaimana masalah dikemukakan, dan bagaimana kontributor menanggapinya. Chapter berikutnya mengambil kursi reviewer.