GitHub Stacked PRs

 (github.github.com/gh-stack)
9 poin oleh GN⁺ 9 hari lalu | 1 komentar | Bagikan ke WhatsApp
  • Fitur baru GitHub yang memungkinkan membagi perubahan kode skala besar menjadi unit PR kecil yang mudah ditinjau lalu mengelolanya secara berurutan
  • Setiap PR dapat ditinjau secara mandiri, dan seluruh stack bisa digabungkan dengan satu klik
  • Melalui UI GitHub dan CLI gh stack, pengguna dapat membuat, menelusuri, me-rebase, dan menggabungkan stack, serta memvisualisasikan hierarkinya dengan stack map
  • Melalui integrasi agen coding AI, diff besar dapat otomatis dipecah menjadi unit stack atau digunakan untuk menjalankan pengembangan berbasis stack
  • Tujuannya adalah mengurangi kompleksitas dan risiko konflik pada PR besar, serta meningkatkan efisiensi review dan kecepatan pengembangan tim

Fitur utama

  • Manajemen PR bertumpuk

    • Menyusun beberapa PR dalam bentuk stack yang berurutan, di mana setiap PR berbasis pada branch PR tepat di bawahnya
    • Membentuk struktur rantai yang pada akhirnya mencapai branch utama
    • GitHub mengenali seluruh stack dan menampilkan stack map di UI, sehingga reviewer dapat menelusuri tiap lapisan dengan mudah
    • Aturan perlindungan branch diterapkan pada branch target akhir, dan pengujian CI dijalankan untuk semua PR dalam stack

  • Pengelolaan stack yang disederhanakan

    • Di UI GitHub, pengguna dapat berpindah antar-PR dalam stack, memeriksa status tiap lapisan, dan menjalankan cascading rebase untuk seluruh stack
    • Seluruh stack atau hanya sebagian dapat digabungkan dengan satu klik
    • Setelah penggabungan, PR yang tersisa akan otomatis di-rebase, sehingga PR terbawah yang belum digabungkan akan disesuaikan untuk menargetkan branch dasar

  • Dukungan CLI yang kuat

    • Melalui CLI gh stack, pengguna dapat membuat stack, me-rebase, push branch, membuat PR, dan berpindah antar-lapisan langsung dari terminal
    • Contoh perintah CLI
      • gh extension install github/gh-stack : memasang ekstensi
      • gh stack alias : mengatur perintah pintas
      • gs init <branch> : membuat branch pertama
      • gs add <branch> : menambahkan lapisan baru
      • gs push : push semua branch
      • gs submit : membuat PR untuk seluruh stack

  • Integrasi AI Agent

    • Dengan perintah npx skills add github/gh-stack, agen coding AI dapat dipersiapkan untuk menjalankan pekerjaan berbasis stack
    • Diff besar dapat secara otomatis dipisahkan menjadi unit stack, atau pengembangan berbasis stack dapat dijalankan sejak awal

Mengapa PR bertumpuk diperlukan

  • PR besar menyebabkan review makin sulit, penggabungan tertunda, dan risiko konflik meningkat
    • Reviewer kehilangan konteks, kualitas umpan balik menurun, dan kecepatan tim secara keseluruhan melambat
  • Stacked PRs mengatasi hal ini dengan membaginya menjadi rantai PR kecil yang terfokus
    • Setiap PR dapat ditinjau secara mandiri, sementara seluruh perubahan terakumulasi secara berurutan

Memulai

Bacaan terkait

1 komentar

 
GN⁺ 9 hari lalu
Komentar Hacker News

  • Yang saya butuhkan bukan "stacked PR", melainkan UI untuk mengelola commit tunggal

    • Saya ingin bisa me-merge hanya sebagian commit secara independen, atau menandai commit tertentu sebagai selesai direview
    • Saya ingin melakukan interactive rebase/squash/edit per commit, tetapi itu tidak bisa dilakukan di UI GitHub
    • Diperlukan fitur untuk memberi komentar pada pesan commit atau commit tertentu, serta fitur untuk memvisualisasikan perubahan antar force push dengan diff of diff
      Git sudah punya konsep commit, jadi saya tidak paham kenapa harus menambahkan abstraksi lain bernama “stacked PR” di atasnya
    • Ini adalah konsep yang membawa workflow stacked diff buatan Phabricator ke GitHub
      Ini memudahkan melanjutkan pekerjaan di atas pekerjaan yang belum di-merge, dan memungkinkan reviewer melakukan review independen dalam unit-unit kecil pada perubahan besar
      Ini sangat berguna terutama di monorepo skala besar atau lingkungan perusahaan
    • Tapi saya merasa terus-menerus menulis ulang riwayat git itu berisiko
      Mengulang squash, rebase, dan force push terasa seperti menodongkan senjata ke kaki sendiri
      git merge --no-ff, git log --first-parent, git bisect --first-parent saja sudah cukup untuk mendapatkan efek yang sama
    • SuperSmartLog(SSL) yang saya pakai di Meta adalah implementasi terbaik
      Ini dipublikasikan di dokumentasi interactive smartlog dan juga punya ekstensi VSCode
      Sayang sekali tidak digunakan lebih luas
    • Workflow yang saya sukai adalah melihat PR/MR sebagai “perubahan atomik”
      Commit dipakai sebagai proses evolusi untuk menyelesaikan PR tersebut
      1. Jika PR terlalu besar, bagi menjadi beberapa commit
      2. Catat proses perkembangan PR di commit (termasuk alasan seperti “mengubah foo menjadi bar”)
    • Yang kamu jelaskan pada dasarnya adalah Gerrit

  • Setelah memakai Phabricator dan Mercurial lalu kembali ke GitHub, rasanya seperti kembali ke zaman batu
    Senang melihat jujutsu atau fitur ini menghidupkan kembali alur stacked diff
    Ini membantu membuat review tetap kecil dan cepat, bukan hanya di monorepo tapi juga dalam pengembangan fitur jangka panjang

    • Syukurlah Git yang menang dalam perang DVCS
      Mercurial selalu bilang “lebih cepat dari git”, tapi praktiknya sering lebih lambat atau rusak
      Git itu jelek tapi cepat dan andal
    • Saya masih tidak suka review di GitHub, jadi saya memakai Gerrit
      Saat mereview perubahan besar (mis. pembaruan dependensi vendor), pengalaman review file di GitHub kurang bagus
    • Saya sangat merindukan UI review Phabricator

  • Akhirnya keluar juga!
    Model “PR=branch” di GitHub tidak pernah masuk akal bagi saya
    Stacked commit ala Phabricator/Gerrit lebih cocok dengan cara saya berpikir
    Sekarang saya harus memasang CLI-nya

    • Ketergantungan pada GH CLI agak disayangkan, tapi saya harap saat GA nanti ada dukungan UI
    • Dalam model mental saya, saya tidak terlalu paham perbedaan branch dan stacked PR
      Branch hanyalah menancapkan bendera pada commit, dan meninggalkan beberapa titik hanya bermakna jika bagian sebelumnya bisa di-merge secara independen

  • Saya penasaran apakah ini sudah menyelesaikan masalah UX Squash & Merge saat ini
    Saya menumpuknya secara manual seperti main <- PR A <- PR B <- PR C,
    saat PR A di-merge lebih dulu, PR B berubah menjadi neraka konflik
    UI GitHub otomatis mengubah branch target menjadi main dan menimbulkan konflik aneh
    Saya hanya butuh alat yang “berfungsi dengan baik”

    • Konflik itu kemungkinan besar terjadi karena PR A di-merge dengan squash merge
      Semoga gh stack sync bisa menanganinya dengan rebase --onto
    • Dalam praktiknya, CLI dan server menanganinya dengan git rebase --onto
      Contoh: PR1(main<-A,B), PR2(main<-A,B,C,D), PR3(main<-A,B,C,D,E,F)
      Jika PR1 dan 2 di-merge dengan squash, maka main menjadi S1(A+B), S2(C+D)
      Setelah itu, git rebase --onto S2 D branch3 bisa merapikannya tanpa konflik
    • Dalam workflow saya, kalau A di-merge maka B juga seharusnya sudah di-merge
      Ini bisa diselesaikan dengan git rebase --update-refs --onto origin/main A C
      GH CLI mengotomatiskan proses ini
    • Masalah ini adalah batasan logis git, bukan bug
    • Saya juga setuju ini menjengkelkan dan tidak intuitif
      Tapi pada akhirnya solusinya tetap hanya merapikan commit dengan rebase manual

  • Saat bekerja sendirian, stacked PR hampir tidak dibutuhkan, tetapi kebiasaan membagi perubahan menjadi unit kecil tetap penting
    Karena alat AI (mis. Claude Code) membuat diff besar sekaligus,
    akan menarik jika agen bisa sendiri membagi pekerjaan menjadi unit-unit logis

    • PR sendiri sudah bisa terdiri dari banyak commit, jadi kalau agen tidak bisa menavigasi itu dengan baik, stacked PR pun akan sama saja
    • Saya memakai Claude dan jj bersama-sama agar stack pekerjaan disusun ulang di atas trunk supaya ramah untuk review
    • Jika branch-branch kecil dibuat saling bergantung, akan muncul neraka sinkronisasi saat branch sebelumnya diperbarui
    • Panduan integrasi agen terkait bisa dilihat di halaman web

  • git-spice juga layak dicoba
    Kompatibel dengan GitLab dan lainnya, dan saya memakainya untuk semuanya alih-alih perintah git biasa

  • Keren melihat GitHub akhirnya menambahkan fitur stack di UI
    Mirip dengan glab stack milik GitLab
    Tapi proses merge-nya tampaknya agak canggung — kalau bagian bawah stack di-merge, sisanya akan di-rebase sehingga CI berjalan lagi
    Saat ingin me-merge hanya dua bagian bawah dari tiga patch, Anda harus menunggu masing-masing dites

    • Dalam desain saat ini, kalau CI untuk dua PR bawah lolos, keduanya bisa di-merge sekaligus
      Setelah itu stack bagian atas akan di-rebase dan CI bisa berjalan ulang
      Bagian ini akan ditambahkan dengan lebih jelas ke dokumentasi

  • Saya tidak begitu paham kenapa stacked PR diperlukan
    Di git, set patch sebenarnya bisa direview dan diterapkan secara terpisah
    Model PR justru mengikat semuanya menjadi satu gumpalan
    Stacked PR terlihat seperti abstraksi lain untuk mengakali masalah itu

    • Tim tempat saya bekerja melihat PR itu sendiri sebagai “unit minimum yang bisa diterapkan”
      Commit internal hanya riwayat pengembangan, dan saat merge semuanya digabung jadi satu dengan squash
      Dengan begitu, selama pengembangan kita bebas menumpuk commit, lalu saat merge hanya perubahan bersih yang tersisa
    • Di Phabricator, commit dan diff itu 1:1 jadi terasa jauh lebih alami
      Implementasi GitHub terasa agak seperti fitur tempelan
    • PR pada dasarnya adalah unit perubahan atomik, dan stacked PR memungkinkan Anda bekerja berdasarkan PR baru di atasnya
      Artinya, pekerjaan ditumpuk bertahap dalam unit yang bisa direview

  • Startup bernama Graphite sudah lebih dulu fokus pada stacked PR
    Saya sudah memakai Graphite, dan senang melihat GitHub membuat sesuatu yang mirip

    • Di perusahaan kami juga memakai Graphite dan puas dengannya

  • Saya suka stacked PR, tapi implementasi GitHub kali ini terasa aneh
    Sebenarnya cukup jika tiap branch menunjuk ke parent-nya
    Dibanding CLI, yang lebih dibutuhkan adalah dukungan UI

    • Tapi setelah parent branch di-merge, rebase menjadi menyakitkan
      Akan bagus kalau CLI bisa mengotomatiskan proses ini
    • CLI itu opsional, dan stacked PR juga bisa dibuat dari UI
      Alasan memakai rantai branch adalah agar diff hanya menampilkan perubahan pada branch tersebut
    • Sebenarnya ini sudah bisa dilakukan di git biasa
      Hanya saja UI dan visualisasinya kurang
    • Semoga berikutnya ada peningkatan UI