GitHub memulai pratinjau publik Stacked PR

 (github.blog)
1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Stacked pull requests yang membagi perubahan besar menjadi lapisan kecil yang mudah ditinjau kini diluncurkan bertahap sebagai pratinjau publik untuk semua repositori
  • Setiap PR menargetkan lapisan tepat di bawahnya sehingga anggota tim dapat meninjau diff yang sempit secara paralel dan independen
  • Saat PR paling atas digabungkan, lapisan di bawah yang belum digabungkan ikut diterapkan sekaligus; jika hanya sebagian yang digabungkan, PR di atasnya akan di-rebase otomatis dan targetnya diubah
  • Peninjauan PR yang ada, pemeriksaan wajib, perlindungan branch, dan syarat merge tetap berlaku, serta stack dapat ditangani di GitHub.com, CLI, aplikasi seluler, dan GitHub Copilot
  • Pratinjau publik akan diperluas ke seluruh repositori selama beberapa hari, dan dukungan Merge queue akan tersedia secara bertahap dalam beberapa minggu berikutnya

Struktur PR bertumpuk untuk perubahan kecil

  • Perubahan besar dipecah menjadi beberapa PR kecil dan terfokus, dengan setiap PR disusun sebagai lapisan perubahan yang berurutan
  • Setelah membuat branch dan PR untuk perubahan pertama, branch dan PR tambahan dibuat di atasnya, dan setiap PR menargetkan lapisan tepat di bawahnya
  • Ini mengurangi kerepotan meninjau satu PR besar atau terus melakukan rebase manual pada banyak branch
  • Tim Next.js menilai bahwa mereka bisa merilis fitur besar sambil menjaga tiap perubahan tetap kecil sehingga peninjauan PR menjadi lebih mudah

Pembuatan stack dan lingkungan kerja

  • Ekstensi CLI dipasang dengan perintah berikut
gh extension install github/gh-stack
  • Stack dapat dibuat dan dikelola di GitHub.com, GitHub CLI, dan aplikasi seluler GitHub
  • Pada agen coding seperti GitHub Copilot, skill gh-stack dapat digunakan

Peninjauan independen per lapisan

  • Saat membuka PR dalam stack, yang dapat ditinjau adalah hanya diff pada lapisan tersebut, bukan seluruh perubahan
  • Peta stack di bagian atas PR menunjukkan posisi perubahan saat ini dalam keseluruhan pekerjaan
  • Anggota tim dapat meninjau lapisan yang berbeda secara paralel sehingga pekerjaan berikutnya tidak terhambat sampai peninjauan selesai
  • Aturan perlindungan branch yang ada dapat diterapkan bersama peninjauan per lapisan untuk menjaga kualitas di tiap tahap
  • TED menyatakan bahwa setelah adopsi AI meningkatkan produktivitas pengembangan, PR yang membesar menjadi hambatan peninjauan; dengan membagi perubahan ke unit logis kecil berdasarkan urutan dependensi, mereka meningkatkan kecepatan dan akurasi peninjauan

Menggabungkan seluruh atau sebagian stack

  • Saat PR paling atas yang sudah siap digabungkan, PR tersebut beserta semua lapisan di bawahnya yang belum digabungkan akan diterapkan sekaligus
  • Anda juga bisa lebih dulu menggabungkan sebagian stack dengan memilih satu atau lebih lapisan bawah
    • PR di atasnya tetap dalam keadaan terbuka
    • PR tersebut akan di-rebase otomatis sesuai perubahan yang sudah digabungkan dan branch target-nya juga akan diubah
  • Perlindungan branch, pemeriksaan wajib, dan syarat merge yang ada tetap berlaku untuk mengendalikan perubahan yang masuk ke main
  • Bukan hanya seluruh stack, satu lapisan atau beberapa lapisan saja juga bisa digabungkan secara selektif

Pratinjau publik dan jadwal dukungan

  • Stacked pull requests diluncurkan bertahap sebagai pratinjau publik ke semua repositori selama beberapa hari
  • Dukungan Merge queue akan dirilis bertahap dalam beberapa minggu berikutnya
  • Petunjuk penggunaan lebih lanjut tersedia di dokumentasi stacked pull requests, dan masukan diterima melalui diskusi stacks

Bacaan terkait

1 komentar

 
GN⁺ 1 jam lalu
Opini Hacker News

  • Saya sudah memakai preview ini cukup lama, dan cukup mengejutkan bahwa cakupannya diperluas saat masih ada banyak masalah yang belum terselesaikan
    Misalnya, merge seluruh stack benar-benar rusak dalam berbagai situasi: https://github.com/github/gh-stack/discussions/212
    Memang bisa merge satu per satu, tetapi jika squash merge digunakan bersama review wajib, setiap PR di stack harus disetujui ulang, sehingga manfaat terbesar stacked PR hilang
    gh stack memang sedikit mengurangi kerja manual, tetapi tetap perlu benar-benar memahami git rebase. Jika branch lokal tidak sinkron dengan remote, gh stack rebase yang diarahkan oleh UI pun gagal, dan tool tidak memberi tahu penyebabnya
    Sebaliknya, saya suka UI stack-nya karena sederhana tetapi cukup menunjukkan relasi antar-PR. Dengan asumsi sudah ada alasan untuk menumpuk PR, tool ini hanya membuat alur kerja lebih nyaman, bukan menyediakan fitur baru

    • Perbaikan bug untuk mengatasi masalah squash merge sedang dirilis secara bertahap
      CPRMC (Create Pull Request Merge Commit) internal menentukan kesiapan merge PR dengan memeriksa semuanya, mulai dari ada tidaknya konflik hingga apakah persetujuan benar-benar cocok dengan commit yang akan dibuat
      Untuk melakukan squash merge pada beberapa PR, perlu menghitung rangkaian commit squash lalu menghubungkannya kembali ke aturan dan review. PR pertama relatif mudah, tetapi mulai PR kedua menjadi rumit karena commit leluhur sudah di-squash dan tidak ada lagi dalam bentuk aslinya di branch; situasi dengan banyak parent jauh lebih sulit lagi
      Saat ini 99% merge stack berhasil, tetapi menaikkannya jauh lebih tinggi adalah prioritas utama tim
    • Hari ini saya mengalami bug yang terus macet di status merging tanpa panduan tambahan setelah menghapus branch yang dirujuk oleh stacked PR
      Saya sempat mengecek halaman status GitHub karena mengira ada gangguan parsial pada sistem PR, tetapi ternyata itu bug pada fitur stacked PR itu sendiri
    • Sepertinya sejak 2021 seluruh industri sudah sepenuhnya beralih ke cara siap, tembak, lalu bidik
    • Di perusahaan kami juga belakangan ada sangat banyak masalah karena fitur ini dan merge queue

  • Tim GitHub Stacked PRs kini membukanya lebih luas agar siapa pun dapat membuat stack: https://gh.io/stacks
    Mereka terutama menginginkan masukan tentang UI dan CLI, dan juga menyiapkan banyak pembaruan untuk meningkatkan pengalaman menggunakan PR
    Ini adalah salah satu peluncuran terbesar dalam sejarah GitHub, mencakup hampir semua layanan mulai dari Actions dan protection rules hingga CLI dan aplikasi mobile, jadi mereka juga bisa menjawab pertanyaan tentang keputusan desain dan cara kerja internalnya

    • Hasil percobaan pertama hari ini saya suka
      Karena kami sudah memakai UI lokal sendiri untuk melihat dependensi stacked PR sebagai tree dan mengelola status review/CI tiap PR, akan bagus jika UI web GitHub juga memiliki tree dan indikator status
      Di UI web tampaknya belum ada fitur untuk hanya me-merge PR paling bawah dari stack, tetapi karena alur kerja dan kode yang ada bisa dibagikan, saya berharap itu juga masuk ke tool bawaan GitHub
    • Saya penasaran apakah dalam waktu dekat akan ada dukungan untuk stacked PR lintas fork
      Ini tampak seperti fitur penting agar berguna di repository publik, jadi agak mengejutkan karena belum tersedia sebelum public preview
    • Inilah fitur yang paling saya rindukan dari Gerrit
    • Saya penasaran mengapa tambahan PR dipilih sebagai unit pemecahan pekerjaan
      Alih-alih UI yang benar-benar layak untuk mereview, menerapkan, dan memperbaiki per commit, mereka mengabaikan alur kerja kumpulan patch dari mailing list yang menjadi asal-usul pendekatan ini, dan pada dasarnya memilih “kumpulan dari kumpulan patch”; saya ingin tahu apakah ada wawasan khusus di baliknya

  • Ini termasuk salah satu perubahan terbesar yang diterapkan pada GitHub selama bertahun-tahun
    Dengan diperkenalkannya alur kerja bertumpuk ke salah satu platform hosting kode terbesar di dunia, banyak developer bisa bersentuhan dengan cara kerja yang bahkan tidak mereka ketahui keberadaannya
    Jika premis bahwa stack menghasilkan software yang lebih baik memang benar, kemungkinan besar ini benar-benar akan membantu banyak developer

  • Saya penasaran apa manfaat stacked PR seperti ini dibandingkan mereview commit-commit yang sudah tertata baik satu per satu
    Masalah yang lebih besar adalah PR besar hasil AI memerlukan cara review tersendiri. Sekadar urutan tampilan diff—misalnya menampilkan perubahan definisi fungsi, call site, lalu test—saja bisa sangat memengaruhi keterbacaan
    Mungkin kita membutuhkan literate diff atau literate PR yang menggabungkan diff dan penjelasan, seperti literate programming yang merangkai kode dan prosa, tetapi saya belum menemukan tool yang mirip

    • Bagi orang yang memakai stacked diff di Phabricator dan sejenisnya, ini memang cara mereview commit yang tertata baik satu per satu
      Karena unit review berupa PR atau diff tetap menjadi satu perubahan yang terbatas, diskusi terfokus pada perubahan tersebut, dan meski fiturnya membesar, PR itu sendiri tidak menjadi bengkak
      Selain itu, setiap bagian stack bisa diberikan kepada pihak berbeda. Jika reviewer dibagi—misalnya tim eksternal, rekan satu tim, atau tim yang memakai perubahan tersebut—tidak ada ambiguitas tentang apa yang masing-masing setujui
      Akan lebih baik lagi jika review GitHub memperkenalkan change ID agar komentar tetap bertahan setelah rebase
    • Jika menambahkan commit ke PR pertama dalam stack, commit itu bisa disisipkan di tengah urutan commit keseluruhan
      Bahwa PR berikutnya harus di-rebase dan diperbaiki sama saja dengan memperbaiki commit lanjutan pada satu PR raksasa, tetapi alih-alih menempelkan commit perbaikan sementara secara acak ke seluruh perubahan, lebih mudah menjaga commit perubahan dasar tetap terkumpul
      Diskusi tentang perubahan dasar juga terkumpul bersama, dan jika seluruh stack ditampilkan sejak awal, reviewer bisa memahami arah akhir sementara pekerjaan terus berjalan secara asinkron
    • Intinya, tidak banyak orang yang benar-benar membuat commit yang “tertata baik”
      Mereka memakai commit seperti titik simpan gim, hanya meninggalkan pesan seperti fix bug, do work, lalu tidak merapikannya dengan git rebase -i, sehingga jika squash merge wajib tidak diaktifkan, log akan penuh commit sampah
      Bagi developer seperti ini, PR adalah commit, dan stacked PR akhirnya memungkinkan mereka memakai struktur yang mirip dengan beberapa commit yang membentuk satu perubahan
    • Dengan stack, pekerjaan perubahan panjang bisa terus dilanjutkan sambil terus membuat diff berukuran layak review
      Diff yang sudah di-merge bisa di-rebase di atas HEAD saat ini, dan pada tim yang mendukung ini biasanya branch tidak dikelola langsung; mereka bekerja dari trunk dan melakukan rebase setiap kali ada perubahan masuk
    • Di PR, commit tidak bisa di-merge satu per satu, tetapi di stack bisa
      Jika 4 bagian awal dari sebuah fitur sudah siap dan bagian ke-5 bermasalah, tidak perlu menahan semuanya

  • Penasaran kapan kasus ketika PR yang saling bergantung membentuk struktur pohon, bukan riwayat linear, akan didukung
    Saat menggunakan perubahan bertumpuk di Google, kasus seperti ini umum terjadi, dan sekarang dengan makin banyaknya agen coding paralel, tampaknya akan muncul lebih sering

    • Ini struktur yang bahkan sulit dikelola manusia, jadi saya ragu apakah benar diinginkan membuat perangkat lunak dan AI turunannya mendorong cara seperti ini

  • Penasaran apakah alasan tombol perpindahan menu memakai emoji tumpukan panekuk (U+1F95E) adalah karena fitur stack
    Ekspresi yang bercanda itu sendiri tidak masalah, tetapi itu adalah UI yang menimbulkan kecurigaan kuat tentang apa yang sedang dilihat

  • Sejak pertama mendengar kabarnya, saya memakai CLI gh stack, dan alatnya sendiri sangat bagus, tetapi UI web yang saya akses setelah mendapat persetujuan preview jauh di bawah ekspektasi
    Bahkan sebelum disetujui, CLI memudahkan otomatisasi untuk memecah pekerjaan menjadi beberapa PR atomik, tetapi saat di-push, PR tersebut ditampilkan sebagai PR independen yang tidak saling terhubung
    Setelah disetujui pun hampir sama; satu-satunya perubahan adalah PR lain dalam stack yang sama muncul di dropdown navigasi kecil di bagian atas, jadi tidak ada perubahan UI yang berarti
    Dari dropdown, sebagian fungsi CLI bisa dijalankan, tetapi itu lebih mirip kemudahan tambahan seperti fitur mengedit file di web, dan dalam alur kerja pengembangan nyata CLI atau plugin IDE-lah yang akan menjadi pusatnya
    Saya heran mengapa perilisan umum ditunda begitu lama hanya untuk UI opsional seperti ini, padahal CLI stack sudah tersedia untuk umum sejak diumumkan

    • Awalnya kami harus memulai dengan fitur minimal, tetapi kami sedang mengerjakan perombakan UI PR yang jauh lebih luas
      Ini juga akan mencakup tampilan yang selalu menyadari stack dan terus menampilkan stack agar pengguna bisa berpindah antar-lapisan tanpa banyak klik

  • Hal yang saya sukai dari jujutsu adalah ketika sebuah branch diperbarui, branch lain yang bercabang dari branch itu juga otomatis di-rebase
    Saat membagi pekerjaan agar mudah di-review, saya sering beralih ke jj, dan meski digunakan bersama di direktori kerja yang sama dengan clone yang dibuat lewat Git, semuanya berjalan baik

    • jj absorb juga luar biasa
      Ia memindahkan perubahan ke perubahan terkait yang paling dekat, sehingga perbaikan yang memengaruhi beberapa PR pun mudah ditangani

  • Setelah menggunakan Graphite, sangat sulit kembali ke GitHub tanpa stack
    Dengan dukungan GitHub, saya berharap alur kerja PR bertumpuk menjadi umum dan ada pilihan mudah sebagai pengganti PR raksasa

    • Saya merekomendasikan git-spice
      Mudah digunakan, kuat, dan open source; Graphite terasa terlalu rumit dibandingkan fiturnya

  • Saya memahami penumpukan PR berguna dalam dua situasi
    Pertama, ketika pekerjaan tersebar di beberapa repositori yang saling terkait sehingga tidak bisa digabung menjadi satu PR, dan kedua, ketika mem-pipeline pekerjaan dengan menumpuk PR lanjutan di atas branch yang sama sambil PR pertama sedang di-review
    Namun fitur ini tampaknya tidak memenuhi keduanya, dan terlihat seperti bentuk lain dari menumpuk commit dalam satu PR
    Umumnya kita membuat commit yang atomik dan bermakna, lalu menyusun alur yang mudah dipahami reviewer lewat rebase, dan reviewer pun bisa melihat per commit jika mau
    Saya penasaran apa keuntungan unik yang terlewat dalam pendekatan ini