Cherry-pick — apa itu, mekanisme dan penerapannya di Git

Apa itu Cherry-pick?

Cherry-pick — adalah perintah Git yang menyalin perubahan dari commit yang ditentukan dan menerapkannya sebagai commit baru di cabang saat ini. Nama ini berasal dari metafora “memetik ceri”: pengembang hanya memilih commit yang diperlukan, mengabaikan sisanya.

Berbeda dengan Merge, cherry-pick tidak membuat merge commit dan tidak memerlukan penggabungan penuh cabang. Berbeda dengan Rebase, cherry-pick tidak memindahkan urutan commit — hanya yang ditentukan. Ini menjadikan cherry-pick alat yang ideal untuk pemindahan perbaikan yang tepat.

Menurut data Atlassian, 2025, cherry-pick digunakan di 47% tim yang bekerja dengan beberapa cabang rilis secara bersamaan. Cherry-pick sangat dibutuhkan dalam pengembangan mobile, di mana beberapa versi aplikasi (rilis LTS) didukung secara bersamaan dan diperlukan pemindahan perbaikan di antara mereka.

Mekanisme pemindahan

Saat menjalankan cherry-pick, Git menghitung diff antara commit yang ditentukan dan induknya, kemudian menerapkan diff ini ke cabang saat ini. Jika perubahan diterapkan tanpa konflik — Git membuat commit baru dengan pesan yang sama tetapi SHA baru. Jika ada konflik — cherry-pick dijeda untuk penyelesaian manual.

Bagaimana Cherry-pick bekerja

Sintaks cherry-pick sederhana: tentukan hash commit yang ingin dipindahkan. Git akan menyalin perubahan ke cabang saat ini sebagai commit baru. Pemindahan beberapa commit sekaligus dan seluruh rentang didukung.

# Memindahkan satu commit ke cabang saat ini
git cherry-pick a1b2c3d4

# Memindahkan beberapa commit
git cherry-pick a1b2c3d4 e5f6g7h8

# Memindahkan rentang commit (dari a1b2 hingga f9e8, tidak termasuk a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

Setelah menjalankan cherry-pick, cabang saat ini menerima commit baru dengan perubahan dari yang asli. Pesan commit secara default disalin dari yang asli, tetapi dapat diubah dengan flag -n (jangan buat commit) atau --edit (edit pesan).

Contoh pemindahan perbaikan

Pertimbangkan skenario tipikal: di develop ditemukan dan diperbaiki bug kritis yang juga ada di cabang rilis release/v2.0. Hanya perbaikan ini yang perlu dipindahkan, tanpa menggabungkan seluruh develop ke cabang rilis.

# Temukan hash commit dengan perbaikan di develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Beralih ke cabang rilis
git checkout release/v2.0

# Terapkan perbaikan
git cherry-pick a1b2c3d4

# Jika ada konflik — selesaikan dan lanjutkan
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

Flag -x menambahkan referensi ke SHA asli ke dalam pesan commit: “(cherry picked from commit a1b2c3d4)”. Ini memudahkan pelacakan dari mana commit dipindahkan. Disarankan menggunakan -x di semua skenario, kecuali draf sementara.

Bekerja dengan konflik

Saat konflik, cherry-pick berperilaku seperti merge: Git berhenti dan menandai file yang bertentangan. Pengembang menyelesaikan konflik, melakukan git add dan kemudian git cherry-pick --continue. Untuk membatalkan — git cherry-pick --abort. Flag --strategy memungkinkan menentukan strategi penggabungan (misalnya, recursive dengan opsi).

# Menyelesaikan konflik saat cherry-pick
# Git menampilkan file yang bertentangan
git status

# Selesaikan secara manual, lalu:
git add file_yang_diizinkan.kt
git cherry-pick --continue

# Atau batalkan cherry-pick:
git cherry-pick --abort

Kapan menerapkan Cherry-pick

Cherry-pick optimal dalam skenario di mana diperlukan pemindahan perubahan yang tepat tanpa menggabungkan seluruh cabang. Mari kita lihat lima kasus utama di mana cherry-pick menjadi pilihan terbaik.

• Memindahkan hotfix — perbaikan ditemukan di develop, tetapi perlu diterapkan di cabang rilis (release/v2.0). Cherry-pick hanya memindahkan commit perbaikan, tanpa menyentuh fitur yang belum selesai dari develop
• Backport ke versi lama — perbaikan untuk versi saat ini perlu dipindahkan ke rilis LTS. Alih-alih menggabungkan seluruh basis kode saat ini, cherry-pick hanya memilih commit yang diperlukan
• Membatalkan commit di cabang lain — jika commit dibuat di cabang yang salah, cherry-pick memindahkannya ke cabang yang benar, dan commit asli dibatalkan
• Memindahkan dokumentasi — perubahan di README atau file konfigurasi yang harus ada di semua cabang, nyaman dipindahkan melalui cherry-pick
• Penerapan selektif — dari cabang prototipe hanya perlu mengambil satu commit yang berhasil, tanpa memindahkan seluruh prototipe ke pengembangan utama

Untuk pengembangan mobile, cherry-pick sangat penting saat mendukung beberapa versi aplikasi. Misalnya, jika bug ditemukan di versi 3.2 yang sudah dirilis di Google Play, sementara develop berisi kode untuk versi 4.0 — cherry-pick memungkinkan pemindahan perbaikan ke cabang v3.x tanpa menggabungkan semua breaking changes. Ini sangat relevan untuk proyek di mana dua atau lebih versi utama dengan API dan dependensi berbeda didukung secara bersamaan.

Contoh dari praktik: dalam aplikasi mobile ditemukan crash saat otorisasi melalui Google Sign-In di Android 12. Perbaikan dimasukkan ke develop dan telah melewati review. Namun cabang rilis saat ini v2.5 sudah dalam tahap pengujian beta. Cherry-pick commit perbaikan dari develop ke release/v2.5 memungkinkan perbaikan disertakan dalam rilis berikutnya, tanpa memindahkan perubahan lain yang belum siap untuk dirilis.

Saat menggunakan cherry-pick di proyek mobile penting untuk mempertimbangkan dependensi: jika perbaikan memengaruhi file yang diubah di develop setelah titik percabangan cabang rilis, cherry-pick dapat membawa set perubahan yang tidak lengkap. Dalam kasus seperti itu, perlu diperiksa apakah semua perubahan terkait juga telah dipindahkan, jika tidak aplikasi mungkin tidak dapat dibangun atau berfungsi dengan tidak benar. Selalu periksa build setelah cherry-pick sebelum mendorong perubahan ke cabang bersama.

Cherry-pick vs Merge vs Rebase

Tiga alat utama integrasi perubahan di Git — merge, rebase dan cherry-pick — menyelesaikan tugas yang berbeda. Pilihan tergantung pada berapa banyak perubahan yang perlu dipindahkan dan bagaimana sejarah harus terlihat.

Merge — ketika dua cabang perlu digabungkan sepenuhnya dan informasi tentang percabangan dipertahankan. Rebase — ketika cabang pribadi perlu diperbarui ke keadaan saat ini dengan sejarah yang bersih. Cherry-pick — ketika hanya satu commit atau beberapa commit yang dipilih diperlukan.

Dalam praktiknya, alat-alat ini dikombinasikan: fitur dikembangkan dengan rebase periodik ke develop, kemudian digabungkan melalui --no-ff merge, dan ketika perlu memindahkan perbaikan ke cabang lain, cherry-pick digunakan. Setiap alat menyelesaikan tugasnya pada tahapnya masing-masing.

Risiko dan batasan Cherry-pick

Cherry-pick — alat yang berguna tetapi berpotensi berbahaya jika digunakan secara tidak benar atau berlebihan. Risiko utama terkait dengan duplikasi commit, kehilangan konteks, dan konflik pada penggabungan selanjutnya.

• Duplikasi commit — jika commit yang sama kemudian masuk ke cabang melalui merge, Git akan membuat commit kedua yang identik dalam hal perubahan. Ini mengotori sejarah dan mempersulit git bisect
• Kehilangan konteks — cherry-pick memindahkan diff, tetapi tidak memindahkan informasi tentang commit induk dan dependensi. Jika cherry-pick menerapkan commit A tanpa commit B yang menjadi dependensi A, kesalahan logis dapat terjadi
• Konflik saat merge — setelah cherry-pick, saat penggabungan penuh cabang, Git dapat melihat perubahan yang sama dua kali dan membuat konflik yang bisa dihindari pada merge biasa
• Tidak ada tautan — tanpa flag -x tidak mungkin dipahami bahwa commit dipindahkan dari cabang lain. Saat mencari asal perubahan, pengembang dapat menghabiskan berjam-jam untuk menentukan asal-usul commit

Rekomendasi untuk meminimalkan risiko: selalu gunakan flag -x untuk menunjukkan SHA asli, dokumentasikan alasan cherry-pick di pesan commit, dan bila memungkinkan gunakan merge daripada cherry-pick ketika konteks memungkinkan. Jika cherry-pick terlalu banyak — pertimbangkan restrukturisasi cabang.

Otomatisasi pemeriksaan saat Cherry-pick

Pipeline CI harus mempertimbangkan cherry-pick sebagai skenario terpisah. Disarankan untuk mengatur pemeriksaan otomatis: saat membuat commit cherry-pick, CI memeriksa apakah file yang diubah sesuai dengan set yang diharapkan dan menjalankan tes untuk modul yang terpengaruh. Ini mengurangi risiko regresi saat pemindahan perubahan yang tepat antar cabang.