Coba lakukan cherry-pick pada GitHub PR

• Sudah 4 bulan sejak kami mulai menggunakan mono-repository di internal perusahaan
• Bersamaan dengan mono-repository, kami juga menerapkan trunk-based development, kata kunci yang selalu ikut dibicarakan dalam konteks ini
• Sesuai strategi trunk-based development, kami menggunakan alur dengan melakukan commit ke branch main lalu melakukan cherry-pick ke branch release
• Berdasarkan isi blog teknis LinkedIn, kami menyusun GitHub Action, tetapi belum bisa menyelesaikan CONFLICT secara otomatis. Jika terjadi CONFLICT, pengguna harus menjalankan perintah git cherry-pick sendiri di local
• Saya pun mencoba membuat sendiri plugin gh yang membantu perintah cherry-pick ini.

Cara penggunaan

gh cherry-pick -pr <pr_number> -onto <target_branch> [-merge auto|squash|rebase] [-push]  

• Melalui opsi -merge, kita bisa memilih apakah akan melakukan cherry-pick pada merge commit PR, atau pada commit asli dari PR
  • Jika tidak ditentukan atau menggunakan opsi -merge=auto, strategi merge PR akan diinspeksi secara otomatis lalu diterapkan
• Opsi -push mendukung push otomatis ke remote saat cherry-pick berhasil

Catatan setelah membuatnya

• Saat mengembangkan program yang terus berinteraksi dengan proses dan status eksternal, saya membuat repositori tes terpisah untuk membuat Test Dataset
  • Pengalaman berkontribusi sebelumnya ke proyek libgit2 dan refined-github sangat membantu
• Berbagai hal yang dipelajari untuk meningkatkan pengalaman CLI
  • Pembelajaran saat mencoba membuat docker-cli sendiri juga banyak membantu
• Ternyata membuat program CLI membutuhkan usaha yang cukup besar
  • Mengelola banyak nilai status dalam bentuk pipeline
  • Menyediakan input interface yang intuitif bagi pengguna
  • Memberikan input validation sedini mungkin
  • Mengembalikan sistem pengguna ke keadaan semula, dan lain-lain
  • Awalnya saya memperkirakan bisa selesai dalam sekitar sehari, tetapi pada akhirnya memakan waktu sekitar 5 hari untuk membuatnya (pengembangan untuk perbaikan GitHub Actions Workflow memang berjalan paralel, tetapi tetap saja waktu yang dibutuhkan jauh lebih besar dari perkiraan)

[qncnxnlrla]

Halo~ jika ada commit yang sudah di-merge ke branch main(trunk) dan perlu di-revert, biasanya bagaimana Anda menanganinya?

• Jika di-revert di branch main, apakah branch release juga akan di-cherry-pick?
• Tidak menggunakan revert dan menambahkan commit perbaikan?

Karena sudah banyak commit yang menumpuk, sepertinya ada kasus di mana cherry-pick jadi sulit jika terjadi conflict. Saya penasaran apakah Anda punya pengalaman menangani kasus seperti itu!

[a1eng0]

Halo~ terima kasih sudah meninggalkan balasan!

Jika ada commit yang sudah di-merge ke branch main(trunk) dan perlu di-revert, bagaimana Anda menanganinya?

Kami menentukan cherry-pick dari PR revert yang diajukan ke branch main. Karena seluruh riwayat cherry-pick tetap tersimpan di link PR asli, tidak ada kesulitan dalam pelacakan. Tidak ada pemeriksaan mekanis terpisah yang dilakukan haha

Jika commit sudah menumpuk banyak sehingga terjadi conflict dan cherry-pick menjadi sulit

Pada dasarnya, jika menjalankan trunk-based development, setiap PR berukuran kecil sehingga conflict tidak sering terjadi. Jika conflict memang terjadi, maka kodenya harus ditulis secara manual. Kami juga sering melakukan release agar dukungan untuk versi yang terlalu lama bisa cepat dideprecate, sehingga terhindar dari kondisi di mana bentuk kode berubah terlalu besar!

[lamanus]

Saya kurang paham kenapa strategi ini diperlukan...

[a1eng0]

Jika Anda membaca penjelasan yang diperkenalkan di release-from-trunk, mungkin itu akan membantu Anda memahaminya haha