Bagian 2: Menyiapkan Pull Request

Pull request yang baik menang separuh sebelum dibuka — materi Pull Request merangkumnya dalam satu kalimat, dan bagian ini membuktikannya dari kursi Siti. Bahan yang akan ditimbang reviewer ada dua: riwayat commit dan deskripsi. Riwayat kita saat ini masih memuat satu commit wip yang hanya bermakna bagi penulisnya, dan deskripsi belum tertulis. Kita rapikan keduanya sebelum satu byte pun meninggalkan meja Siti, sehingga branch yang didorong ke fork benar-benar siap ditinjau — dan tidak perlu ditulis ulang setelah review dimulai.

Melihat Keadaan Branch #

Ukur dulu apa yang akan dikirim. Rentang main..review/pencarian menghitung commit milik branch yang belum dimiliki main:

git log --oneline main..review/pencarian

Output yang Dihasilkan:

c12f4c4 wip: tambah hasil uji
c631b60 feat: terapkan fungsi pencarian
84f5f89 feat: tulis kerangka fitur pencarian

Dua commit pertama sudah bercerita baik: kerangka, lalu fungsi. Commit ketiga adalah koreksi kecil yang melengkapi commit kedua — hasil uji adalah bagian dari implementasi fungsi, bukan langkah tersendiri. Pola persisnya sudah dipetakan di Menggabungkan Commit : koreksi kecil yang pesannya layak dibuang adalah kandidat fixup.

Membuka Naskah Riwayat #

Interactive rebase membuka daftar todo — naskah yang bisa kita sunting untuk mengubah bentuk riwayat:

git rebase -i main

Buffer yang terbuka di editor (komentar bantuannya dipotong):

pick 84f5f89 feat: tulis kerangka fitur pencarian
pick c631b60 feat: terapkan fungsi pencarian
pick c12f4c4 wip: tambah hasil uji
(dipotong — sisanya komentar bantuan bawaan Git)

Daftar terbaca dari commit tertua di atas. Suntingannya satu kata: baris ketiga diganti fixup — isinya melebur ke commit di atasnya (feat: terapkan fungsi pencarian), pesan wip-nya dibuang. Dua baris pertama tetap pick.

Menjalankan fixup Tanpa Membuka Editor #

Menyunting buffer secara manual boleh saja; jalur terprogramnya memakai GIT_SEQUENCE_EDITOR — variabel lingkungan yang mengganti editor khusus berkas todo, diperkenalkan di Interactive Rebase :

GIT_SEQUENCE_EDITOR="sed -i 3s/^pick/fixup/" git rebase -i main

Skrip sed mengganti pick menjadi fixup pada baris ketiga file todo — persis suntingan di atas. Keluaran lengkapnya:

Rebasing (3/3)Successfully rebased and updated refs/heads/review/pencarian.

Satu baris ini perlu dibaca pelan. Rebasing (3/3) adalah progres singkat yang di terminal ditimpa baris berikutnya — Git memakai carriage-return, dan pada keluaran yang ditangkap keduanya terekam berurutan. Successfully rebased and updated refs/heads/review/pencarian. menutup sesi: branch berhasil ditulis ulang. Ukur kembali isinya:

git log --oneline main..review/pencarian

Output yang Dihasilkan:

c17159e feat: terapkan fungsi pencarian
84f5f89 feat: tulis kerangka fitur pencarian

Tiga baris menjadi dua, dan wip hilang. Perhatikan kedua hashnya: 84f5f89 tetap sama karena commit pertama tidak tersentuh — rebase memakai ulang objek yang tak berubah. Sebaliknya c17159e adalah objek baru: menulis ulang riwayat selalu melahirkan commit baru bagi yang berubah, karena c631b60 kini harus memuat perubahan c12f4c4 di dalam dirinya. Hash di mesin kita berbeda; perilakunya tidak. Bukti tak ada pekerjaan yang hilang dalam pelipatan:

git diff --stat main..review/pencarian

Output yang Dihasilkan:

 src/feature.txt | 10 ++++++++++
 1 file changed, 10 insertions(+)

Sepuluh baris tambahan atas main — jumlah yang sama seperti sebelum rebase. Riwayat rapi tanpa satu baris pun hilang.

Menulis Deskripsi Pull Request #

Kontrak kedua yang ditimbang reviewer adalah deskripsi. Chapter Pull Request merumuskannya sebagai tiga pertanyaan: apa yang berubah, mengapa perlu, dan bagaimana cara mengujinya. Siti menyusun drafnya sebelum push — disimpan sebagai teks biasa, siap ditempel ke formulir web nanti:

Judul: Tambah pencarian catatan

Apa yang berubah — fungsi cari(kata_kunci) pada src/feature.txt
beserta seksi hasil uji. Dua commit: kerangka seksi, lalu
implementasi fungsi dan ujinya.

Mengapa diperlukan — data catatan tersedia sejak commit rintisan,
tetapi belum ada cara menemukan catatan tertentu tanpa membaca
seluruh daftar.

Cara menguji — baca seksi "Hasil Uji" pada src/feature.txt:
pencarian kata "belanja" mengembalikan catatan 3. Ulangi dengan
kata kunci lain untuk membandingkan hasilnya.

Perhatikan kalimat terakhirnya: deskripsi ini berjanji bahwa fungsi mencari kata kunci apa pun. Janji itulah yang nanti disandingkan reviewer dengan isi diff — dan disanalah letak kejutan yang menunggu di Bagian 3.

Push ke Fork #

Branch siap dikirim. Dorong ke origin — remote yang menunjuk fork milik Siti sendiri:

git push -u origin review/pencarian

Output yang Dihasilkan:

To ../fork-siti.git
 * [new branch]      review/pencarian -> review/pencarian
branch 'review/pencarian' set up to track 'origin/review/pencarian'.

Opsi -u memasang hubungan pelacakan antara review/pencarian lokal dengan origin/review/pencarian — materi Upstream Branch . Yang penting dicatat: push ini menyentuh fork saja. Repository asal sama sekali tidak tahu branch ini ada.

Pull Request Dibuat di Web #

Dari titik ini satu langkah hidup di peramban, bukan di terminal — tidak ada perintah git pull-request, karena pull request adalah fitur platform. Platform mendeteksi branch yang baru terdorong di fork dan menampilkan tombol pembandingan di halamannya. Siti mengklik tombol itu, lalu mengisi formulirnya: base adalah main milik upstream — perbandingan lintas repository, perbedaan khasnya dari pull request antar branch dalam satu repo — dan compare adalah review/pencarian milik fork. Judul dan deskripsi ditempel dari draf di atas, platform memberi nomor urut #8, dan halaman PR menampilkan daftar commit beserta diff yang dihitung langsung dari kedua branch di server. Karena main upstream belum bergerak sejak Siti membuat branch, kedua riwayat sejalan dan statusnya menyatakan siap di-merge. Alur lengkapnya — termasuk tampilan tiap tombolnya — dibedah di Fork dan Pull Request .

Meja Budi: Mengambil Kandidat #

Panggung berpindah ke clone review Budi. Budi mendaftarkan fork Siti sebagai remote bernama fork:

cd ../budi
git remote add fork ../fork-siti.git
git remote -v

Output yang Dihasilkan (perintah git remote -v):

fork	../fork-siti.git (fetch)
fork	../fork-siti.git (push)
origin	../upstream-catatan.git (fetch)
origin	../upstream-catatan.git (push)

Buku alamat Budi kini berisi dua entri: origin menunjuk repository asal yang dia miliki, fork menunjuk salinan Siti. Tarik branch kandidat dari sana:

git fetch fork

Output yang Dihasilkan:

From ../fork-siti
 * [new branch]      main             -> fork/main
 * [new branch]      review/pencarian -> fork/review/pencarian

Dua branch ditarik sekaligus. Baris pertama adalah main milik fork — salinan main upstream yang identik, karena memang begitulah fork dilahirkan. Baris kedua branch kandidat yang dicari. Perhatikan penulisannya: remote-tracking branch bernama fork/review/pencarian — nama remote di depan, nama branch ber-garis-miring utuh di belakang, persis tip dari Bagian 1. Kandidat kini duduk di meja reviewer, dan pekerjaan Budi dimulai: Bagian 3: Melakukan Code Review .