GitHub Lancar Stacked Pull Requests: Semak Perubahan Kod Besar Secara Bertingkat

Perubahan besar pada aplikasi sering menggabungkan banyak perkara: struktur data, logik pelayan dan paparan pengguna. Apabila semuanya dihantar untuk semakan serentak, rakan sepasukan perlu memahami beberapa keputusan reka bentuk dalam satu masa. Memecahkan kerja membantu, tetapi hubungan antara perubahan juga perlu jelas.

Pada 6 Oktober 2026, GitHub mengumumkan ketersediaan umum stacked pull requests, iaitu permintaan penggabungan kod yang disusun mengikut kebergantungan. Perkembangan ini membuka ruang untuk pasukan menilai semula cara mereka menyediakan kod untuk semakan, termasuk pasukan pembangunan dan pelajar IT di Malaysia.

Apa yang diumumkan GitHub

Menurut pengumuman GitHub, ciri ini tersedia pada semua pelan github.com. Sokongan GitHub Enterprise Server pula dinyatakan untuk keluaran akan datang; pengumuman tersebut tidak bermaksud pemasangan pelayan organisasi sudah memilikinya.

Antara penambahbaikan ialah kelulusan semakan dikekalkan apabila susunan dikemas kini selepas cabang asas berubah, dengan syarat kod berkenaan tidak berubah. GitHub turut menyatakan penggabungan automatik untuk susunan akan dilancarkan berperingkat dalam beberapa minggu selepas pengumuman. Oleh itu, jangan menganggap semua penambahbaikan muncul serentak pada setiap akaun.

Sumber: Stacked pull requests generally available.

Bagaimana semakan bertingkat berfungsi

Dokumentasi GitHub menerangkan bahawa susunan ini mengandungi sekurang-kurangnya dua pull request dalam repositori yang sama. Permintaan paling bawah menyasarkan cabang asas, lazimnya main. Setiap permintaan berikutnya menyasarkan cabang di bawahnya, membentuk rantaian perubahan yang saling bergantung.

Paparan perbezaan kod bagi setiap lapisan menunjukkan perubahan berbanding lapisan di bawahnya. Semua cabang mesti berada dalam repositori yang sama; susunan merentas fork tidak disokong. Dokumentasi juga menyatakan ciri ini tidak disokong dalam GitHub Desktop.

Sebagai analogi editorial, bayangkan menyemak pembinaan rak: tapaknya perlu difahami sebelum penyambung dan tingkat atas dinilai. Pembahagian itu membantu pembaca mengikuti alasan setiap perubahan, tetapi keseluruhan struktur masih perlu masuk akal.

Sumber: About stacked pull requests.

Kelulusan setiap lapisan tetap diperlukan

Menurut dokumentasi, syarat penggabungan ditentukan oleh cabang asas susunan. Perlindungan cabang, termasuk kelulusan pemilik kod, dikenakan pada setiap pull request. Penggabungan bergerak dari bawah ke atas, dan boleh melibatkan keseluruhan susunan atau sebahagiannya.

Tafsiran editorialnya: susunan yang kemas perlu disertai penerangan yang kemas. Penyemak masih perlu tahu tujuan perubahan, andaian yang digunakan dan bukti ujian. Label kecil pada beberapa pull request tidak membantu jika setiap satunya hanya memindahkan kekeliruan ke lapisan seterusnya.

Sumber: About stacked pull requests.

Perhatikan penggunaan ujian automatik

Panduan GitHub Actions menjelaskan bahawa aliran kerja dinilai seolah-olah setiap pull request menyasarkan cabang asas susunan. Aliran kerja yang ditetapkan untuk pull request ke main boleh berjalan pada setiap lapisan. Ini mengekalkan liputan pemeriksaan, tetapi turut meningkatkan bilangan pelaksanaan CI, iaitu integrasi berterusan.

GitHub menyediakan metadata tentang saiz susunan dan kedudukan lapisan untuk membantu menentukan tempat tugas ujian dijalankan. Panduannya menunjukkan cara mengenal pasti lapisan teratas atau permintaan paling bawah yang belum digabungkan.

Sebagai pertimbangan editorial, pengurangan ujian berulang perlu dinilai bersama risiko. Jangan memilih satu lapisan sahaja semata-mata kerana ia paling menjimatkan masa; tentukan dahulu keadaan kod yang benar-benar akan digabungkan dan bukti yang diperlukan untuk meluluskannya.

Sumber: Optimizing CI for stacked pull requests.

Cadangan editorial untuk pasukan di Malaysia

Cadangan berikut ialah contoh latihan kami, bukannya laporan penggunaan oleh syarikat tempatan. Pasukan kecil atau kumpulan projek universiti boleh mencuba satu ciri pada repositori latihan. Contohnya, bina fungsi permohonan cuti dengan lapisan struktur data, peraturan permohonan dan paparan borang.

Tetapkan satu tujuan jelas bagi setiap lapisan. Minta penyemak menerangkan semula perubahan tersebut sebelum meluluskannya. Jika penerangan masih memerlukan mereka membaca semua lapisan sekali gus, pertimbangkan semula sempadan pembahagian kerja. Matlamat latihan ialah menjadikan keputusan lebih mudah dinilai.

Sertakan ujian yang berkaitan bersama perubahan masing-masing. Untuk contoh permohonan cuti, bincangkan tarikh tidak sah, permohonan bertindih dan tindakan pengguna tanpa kebenaran. Catat juga bagaimana pasukan akan membatalkan perubahan jika masalah ditemui selepas penggabungan.

Selepas percubaan, bandingkan pengalaman penyemak, masa menunggu maklum balas dan bilangan pelaksanaan ujian dengan aliran kerja biasa. Pelajar boleh memasukkan penerangan keputusan serta bukti ujian dalam portfolio. Nilainya terletak pada keupayaan menunjukkan proses kerja yang boleh difahami dan dinilai oleh orang lain.

Rujukan

• Stacked pull requests generally available — 2026-10-06
• About stacked pull requests
• Optimizing CI for stacked pull requests

Disediakan secara automatik dengan bantuan AI berdasarkan sumber yang dipautkan. Semakan sumber: 2026-10-13. Gambar utama ialah ilustrasi janaan AI, bukan foto peristiwa sebenar.