Pull request lebih kecil, rilis lebih cepat: apa yang diubah stacked pull request GitHub

Stacked pull request kini generally available di GitHub. Diumumkan pada 6 Oktober 2026, fitur ini memungkinkan tim memecah perubahan besar menjadi beberapa pull request kecil yang di-review terpisah lalu di-merge bersamaan. GitHub mencatat repository yang memakai stack menghasilkan 9% lebih banyak kode yang di-merge dibanding repository serupa selama masa preview.

Kalau kamu menjalankan produk software, ini penting karena satu alasan sederhana: perubahan besar adalah titik di mana rilis melambat. Artikel ini membahas apa yang diumumkan GitHub, cara kerja stack, dan kebiasaan review yang kami pakai untuk merilis fitur ke klien setiap minggu.

Apa yang diumumkan GitHub

• 9% lebih banyak kode yang di-merge di repository yang memakai stack, dibanding repository serupa, sejak fitur ini masuk public preview.
• Lebih dari dua pertiga dari 1% repository teratas kini memakai stacked pull request, dengan time-to-merge 5% lebih cepat.
• Auto-merge untuk stack bergulir dalam beberapa minggu ke depan, sehingga satu stack bisa di-merge otomatis saat syarat repository terpenuhi.

Cara kerja stacked pull request

1. 1Pecah perubahannya. Satu fitur besar menjadi beberapa pull request kecil, masing-masing dibangun di atas yang sebelumnya.
2. 2Review tiap bagian. Reviewer memeriksa satu perubahan yang fokus dalam satu waktu, bukan satu diff raksasa.
3. 3Approval tetap aman. Saat stack tanpa perubahan kode di-rebase setelah branch utama bergerak maju, approval kini tetap tersimpan, dan commit hasil rebase tetap bertanda tangan.
4. 4Merge bersamaan. Stack masuk merge queue sebagai satu kelompok. Kalau base branch stack dihapus, GitHub otomatis mengarahkannya ke branch lain.

Untuk developer yang bekerja dari terminal atau dengan AI coding agent, ekstensi gh stack untuk GitHub CLI kini mendukung Git worktrees.

Kenapa perubahan kecil lebih cepat rilis

Dari pengalaman kami, sebagian besar keterlambatan proyek software bukan di proses menulis kode, melainkan di proses menunggu: menunggu review, menunggu testing, menunggu ada yang cukup yakin untuk merilis. Perubahan besar menunggu paling lama, karena tidak ada yang bisa memeriksa ribuan baris kode dengan cepat dan aman.

Perubahan kecil yang fokus membalik keadaan itu. Lebih mudah di-review, lebih mudah diuji, dan lebih mudah dibatalkan kalau ada masalah. Stacked pull request membuat cara ini praktis bahkan untuk fitur besar, karena pekerjaan bisa dipecah tanpa kehilangan hubungan antarbagiannya.

Kebiasaan agar fitur lebih cepat rilis

Berikut kebiasaan yang kami sarankan berdasarkan pengalaman proyek. Semuanya bisa dipakai dengan atau tanpa stack:

1. 1Jaga tiap perubahan tetap kecil, cukup untuk di-review dalam sekali duduk.
2. 2Satu tujuan per pull request. Perbaikan bug dan fitur baru sebaiknya tidak digabung.
3. 3Tes otomatis di setiap perubahan, dijalankan oleh pipeline CI, supaya reviewer fokus pada logika, bukan hal dasar. Artikel kami tentang perubahan GitHub Actions membahas cara menjaga pipeline tetap sehat.
4. 4Review dalam satu hari kerja, supaya perubahan tidak menumpuk.
5. 5Rilis dengan feature flag kalau sebuah fitur butuh beberapa kali rilis untuk selesai.
6. 6Demo progres setiap minggu, supaya pemilik produk melihat produknya terbentuk.

Artinya untuk bisnismu

Kamu tidak perlu tahu apa itu pull request untuk merasakan manfaatnya. Yang akan terasa adalah ritmenya: tim yang bekerja dalam langkah kecil yang di-review bisa menunjukkan hal baru setiap minggu, dan cepat memperbaiki masalah saat muncul. Kami sarankan menanyakan ke calon mitra pengembang bagaimana mereka me-review dan merilis perubahan, bukan hanya seberapa cepat mereka menulis kode.

Kalau kamu sedang merencanakan produk baru, panduan pengembangan MVP kami menjelaskan cara mulai dari yang kecil dan berkembang dari masukan nyata.

Bagaimana Estontinc membantu

Estontinc adalah software house di Malang dengan 100+ proyek dan 50+ klien selama lebih dari enam tahun. Lewat layanan pembuatan website dan web app serta custom software, kami membangun dalam langkah kecil yang di-review, menjalankan tes otomatis di setiap perubahan, dan menunjukkan progres lewat demo mingguan.

Source code menjadi milikmu, dan proyek harga tetap mendapat dukungan gratis 30 hari setelah rilis. Ceritakan produkmu lewat halaman kontak, dan kami balas dalam 24 jam.