Cherry-pick: apa itu, bagaimana melakukan cherry-pick dan perintah Git

Apa itu cherry-pick di Git

Cherry-pick — adalah perintah git cherry-pick yang mengambil perubahan dari komit yang ada dan menerapkannya sebagai komit baru di cabang saat ini. Komit asli tetap berada di tempatnya di cabang asli, sementara salinan perubahan dibuat di cabang tujuan. Perintah ini berguna ketika Anda perlu memindahkan perbaikan tertentu tanpa memindahkan seluruh cabang.

Sintaks: git cherry-pick <commit-hash>. Git menganalisis perbedaan (diff) dari komit yang ditentukan dengan induknya dan menerapkan perbedaan ini ke cabang saat ini. Jika perubahan melibatkan beberapa file — semuanya dipindahkan bersama. Perintah ini juga menerima rentang: git cherry-pick A..B — semua komit dari A hingga B, tidak termasuk A.

Flag memperluas kemampuan: -n (--no-commit) menerapkan perubahan ke direktori kerja dan indeks tanpa membuat komit — berguna ketika Anda perlu menggabungkan perubahan dari beberapa komit menjadi satu. Flag -x menambahkan baris (cherry picked from commit ...) ke pesan komit, yang memudahkan pelacakan asal perubahan dalam riwayat.

# Cherry-pick satu komit berdasarkan hash
git cherry-pick a1b2c3d

# Cherry-pick beberapa komit (berurutan)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Cherry-pick tanpa komit otomatis
git cherry-pick -n a1b2c3d

# Flag -x menambahkan referensi ke komit asli
git cherry-pick -x a1b2c3d

Kapan menggunakan cherry-pick

Skenario utama — memindahkan perbaikan antar cabang rilis. Bayangkan: di develop ditemukan dan diperbaiki bug kritis. Cabang rilis release/v2.1 sudah dipisahkan dan bug ini juga ada di dalamnya. Merge seluruh develop ke release akan membawa banyak kode yang belum siap, sementara cherry-pick satu komit perbaikan adalah solusi yang aman dan tepat.

Skenario kedua — membatalkan perubahan (revert) dengan pemulihan selanjutnya. Jika komit telah dibatalkan melalui git revert, dan kemudian ternyata pembatalan itu salah — cherry-pick komit yang dibatalkan akan memulihkan perubahan. Ini lebih tepat daripada membatalkan revert, karena tidak menimbulkan konflik berulang.

Skenario ketiga — menggabungkan komit dari berbagai cabang fitur ke dalam satu cabang pengujian untuk pengujian integrasi. Alih-alih menggabungkan beberapa cabang yang belum selesai (dengan kode yang belum jadi), Anda dapat memilih hanya komit yang sudah jadi dari masing-masing cabang dan menguji kerja sama mereka.

• Perbaikan bug — memindahkan perbaikan dari develop ke release tanpa kode yang belum selesai.
• Hotfix — menerapkan perbaikan dari cabang hotfix ke main dan develop secara bersamaan.
• Pembatalan revert yang salah — cherry-pick komit yang dibatalkan untuk memulihkan perubahan.
• Pengujian — mengumpulkan komit terpilih dari berbagai cabang untuk pemeriksaan integrasi.

Cherry-pick vs rebase dan merge

Cherry-pick berbeda dari rebase dan merge karena bekerja pada tingkat komit individual, bukan seluruh cabang. Jika rebase memindahkan semua komit cabang, dan merge menggabungkan dua cabang, maka cherry-pick hanya memilih yang diperlukan. Ini membuatnya menjadi alat yang lebih tepat, tetapi juga lebih manual.

Perbedaan lainnya — kepengarangan. Saat cherry-pick, Git secara default mempertahankan penulis (Author) komit asli, tetapi committer (Committer) menjadi pengguna saat ini. Dalam pesan komit, asal dapat dilacak melalui flag -x. Pada rebase, penulis dan committer keduanya adalah pengguna saat ini dengan hash baru.

Kinerja: cherry-pick satu komit lebih cepat daripada merge dua cabang dengan banyak komit. Tetapi jika perlu memindahkan puluhan komit, lebih baik membuat cabang sementara dan melakukan rebase — ini lebih efisien dan tidak memerlukan menentukan puluhan hash.

Memindahkan beberapa komit

Beberapa komit dapat dipindahkan dengan satu perintah, dengan mencantumkan hash-nya yang dipisahkan spasi: git cherry-pick A B C. Git menerapkan komit secara berurutan dalam urutan yang ditentukan. Jika salah satu komit menyebabkan konflik, cherry-pick berhenti dan pengembang harus menyelesaikan konflik, setelah itu dapat melanjutkan dengan perintah git cherry-pick --continue.

Rentang komit: git cherry-pick A..B (semua komit setelah A hingga B, tidak termasuk A) dan git cherry-pick A^..B (semua komit dari A termasuk hingga B). Rentang berguna ketika perlu memindahkan semua komit dari satu cabang tetapi tanpa hubungan induk — misalnya, saat memindahkan fitur yang sudah jadi dari cabang lama ke cabang baru.

Flag --strategy menentukan bagaimana Git akan menerapkan perubahan. Secara default, strategi recursive digunakan, tetapi Anda dapat menentukan ours atau theirs untuk pemilihan otomatis sisi konflik. Flag --mainline digunakan saat cherry-pick komit merge — menentukan nomor induk (1 atau 2) relatif terhadap mana diff dihitung.

# Cherry-pick rentang komit
git cherry-pick develop~5..develop~2

# Cherry-pick komit merge (tentukan induk)
git cherry-pick -m 1 m9n0o1p

# Menggunakan strategi theirs
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Lanjutkan setelah penyelesaian konflik
git cherry-pick --continue

Konflik saat cherry-pick

Konflik saat cherry-pick terjadi ketika perubahan dari komit yang dipindahkan menyentuh baris yang sama yang telah diubah di cabang tujuan. Git menghentikan eksekusi, menandai file yang bertentangan, dan menunggu penyelesaian. Dalam status, file tersebut ditampilkan sebagai both modified.

Langkah-langkah saat konflik: buka file yang bertentangan, temukan penanda konflik (<<<<<<<, =======, >>>>>>>), edit konten, hapus penanda, jalankan git add untuk file yang telah diselesaikan, dan jalankan git cherry-pick --continue. Jika konflik tidak dapat diselesaikan — git cherry-pick --abort membatalkan seluruh cherry-pick, mengembalikan cabang ke keadaan semula.

Masalah umum: komit sudah berisi perubahan yang setara dengan yang sudah ada. Dalam kasus ini, Git melaporkan «nothing to commit» atau «empty commit» saat mencoba cherry-pick. Flag --keep-redundant-commits dan --empty=keep memaksa Git untuk membuat komit kosong untuk mempertahankan urutan, sementara --skip memungkinkan melewatkan komit tersebut.

# Konflik saat cherry-pick — berhenti
git cherry-pick a1b2c3d
# error: could not apply a1b2c3d... commit message

# Selesaikan konflik → tambahkan ke indeks
git add src/conflicted_file.swift
git cherry-pick --continue

# Lewati komit kosong (sudah diterapkan)
git cherry-pick --skip

# Batalkan sepenuhnya
git cherry-pick --abort

Praktik terbaik cherry-pick

Aturan pertama: selalu periksa apakah komit yang dipindahkan mandiri. Jika komit A bergantung pada perubahan di komit B yang tidak dipindahkan, cherry-pick A dapat merusak build. Sebelum cherry-pick, ada baiknya memeriksa file apa saja yang diubah oleh komit melalui git show --stat <hash>.

Aturan kedua: dokumentasikan cherry-pick. Gunakan flag -x agar pesan komit menyimpan referensi ke komit asli. Ini akan membantu dalam analisis riwayat selanjutnya untuk memahami dari mana perubahan berasal. Tanpa -x, cherry-pick terlihat seperti komit biasa, dan asalnya hanya dapat dilacak melalui git log --graph.

Aturan ketiga: hindari cherry-pick antar cabang yang terlalu berbeda. Jika sudah banyak waktu berlalu sejak pembuatan komit dan basis kode telah berubah secara signifikan, konflik akan banyak dan rumit. Dalam kasus seperti itu, lebih baik membuat perbaikan baru di cabang tujuan — ini akan memakan waktu lebih sedikit daripada menyelesaikan puluhan konflik.

• Cherry-pick hanya komit mandiri tanpa ketergantungan eksternal.
• Flag -x wajib untuk mendokumentasikan asal komit dalam pesan.
• Hindari cherry-pick komit lama dengan perbedaan besar dalam basis kode.
• CI/CD periksa build setelah cherry-pick: konflik mungkin tidak terjadi, tetapi kode mungkin tidak dapat dikompilasi.
• Komentar di PR saat membuat pull request, sebutkan komit mana yang dipindahkan melalui cherry-pick.