Git Cherry Pick: Banyak Commit, Branch, dan Konflik

TL;DR: git cherry-pick <sha> menyalin satu commit dari branch mana pun ke branch Anda saat ini — patch yang sama, SHA baru, tidak ada riwayat yang dipindahkan. Untuk beberapa commit, daftarkan SHA-nya satu per satu atau pakai rentang (git cherry-pick A..B); ingat, rentang itu mengecualikan A, jadi tulis A^..B untuk menyertakannya. Jika berhenti karena konflik, selesaikan, git add, lalu git cherry-pick --continue. Cherry-pick untuk memindahkan satu perbaikan spesifik — saat Anda menginginkan semuanya dari branch lain, gunakan merge atau rebase.

Apa yang sebenarnya dilakukan git cherry-pick?

Cherry-pick mengambil commit yang sudah ada dan menerapkan diff-nya sebagai commit baru di branch Anda saat ini. Commit aslinya tetap di tempatnya; salinannya mendapat SHA baru. Git tidak “memindahkan” apa pun — orang yang kemudian bertanya-tanya kenapa commit itu masih tampil di branch lama sedang melihat persis hal ini.

Model salin-bukan-pindah inilah yang menentukan kapan cherry-pick adalah alat yang tepat:

• Anda butuh satu perbaikan dari feature branch di main sekarang juga, tanpa me-merge sisanya.
• Hotfix yang ter-commit di branch yang salah harus mendarat di branch yang benar.
• Sebuah patch harus diputar ulang ke release branch yang tidak pernah me-merge dari main.

Keterampilan pelengkapnya adalah tahu cara menarik balik commit yang ternyata salah — mekaniknya dibahas di git undo last commit: pertahankan perubahannya.

Bagaimana cherry-pick commit dari branch lain?

Temukan SHA-nya, pindah ke branch tujuan, petik:

# 1. Temukan commit di branch sumber
git log feature/payment-fix --oneline -5

# 2. Pindah ke branch yang harus menerimanya
git switch main

# 3. Salin ke sana
git cherry-pick 1a2b3c4

Dua kenyamanan yang layak diketahui:

• git cherry-pick <branch> memetik commit ujung (tip) branch itu — praktis, tetapi mudah terjadi tanpa sengaja saat bayangan Anda tentang “apa itu ujung branch” sudah basi.
• Setelah pick, git log -1 --stat mengonfirmasi apa yang mendarat. Satu detik membaca, menghemat satu revert.

Commit-commit itu tetap berada di feature/payment-fix; hapus branch itu kapan pun Anda suka — salinan yang dipetik di main punya SHA sendiri dan tidak bergantung pada yang lama.

Bagaimana cherry-pick beberapa commit sekaligus?

Tiga bentuk, diurutkan dari yang paling sering Anda perlukan:

# 1. Daftar eksplisit — dipetik sesuai urutan yang Anda tulis
git cherry-pick 1a2b3c4 5d6e7f8

# 2. Rentang — semuanya setelah A sampai dengan dan termasuk B
git cherry-pick A..B

# 3. Rentang yang menyertakan A
git cherry-pick A^..B

Pembedaan A..B vs A^..B adalah kejutan klasik: A..B mengecualikan A. Jika Anda memvisualisasikan rentang dari git log dan memetik oldest..newest, commit tertua terlewati tanpa suara. Ketika tujuannya “beberapa commit tertua, berurutan”, tulis oldest^..newest dan off-by-one-nya lenyap.

Untuk melipat beberapa pick menjadi satu commit alih-alih tiga, stage tanpa commit dengan -n / --no-commit, lalu commit sekali:

git cherry-pick -n 1a2b3c4 5d6e7f8
git commit -m "Backport: payment retry fixes"

Kenapa git cherry-pick tidak berfungsi?

Empat penyebab nyata, diurutkan dari yang paling sering:

1. Konflik menghentikan pick. Git menerapkan patch, menabrak baris yang berubah di kedua branch, dan berhenti di tengah urutan:

# selesaikan file-filenya, lalu:
git add <resolved-files>
git cherry-pick --continue   # atau --abort untuk kembali ke kondisi sebelum pick

--continue bukan opsional dan tidak tersirat — sampai Anda menjalankannya, Anda berada di dalam urutan cherry-pick yang dijeda dan git status akan terus mengingatkan itu.

2. Pick-nya kosong (“The previous cherry-pick is now empty”). Perubahannya sudah ada di branch ini, sering kali dari pick sebelumnya atau merge yang di-squash. Lewati dengan git cherry-pick --skip, atau paksa commit kosong dengan --allow-empty jika Anda memang butuh penandanya.

3. Commit-nya adalah merge commit. Merge punya dua orang tua, jadi “terapkan diff ini” menjadi ambigu — git menolak alih-alih menebak. Sebutkan orang tua mana yang menjadi dasar diff Anda:

git cherry-pick -m 1 <merge-sha>   # parent 1 = branch tempat Anda me-merge *ke dalamnya*

4. Working tree yang salah atau detached HEAD. Pick mendarat di mana pun HEAD menunjuk. Jalankan git branch --show-current sebelum memetik; jika tidak mencetak apa pun, Anda sedang detached HEAD dan commit akan menjadi yatim saat Anda berpindah.

Cherry-pick vs merge vs rebase: pakai yang mana, kapan?

Perintah	Yang mendarat di target	Riwayat	Pakai saat
git cherry-pick <sha>	Hanya commit yang disebut	Salinan, SHA baru	Satu perbaikan spesifik harus pindah sekarang
git merge <branch>	Semuanya di branch itu	Merge commit atau fast-forward	Anda ingin seluruh branch, divergensi terlihat
git rebase <base>	Semua commit branch, diputar ulang	Linier, SHA ditulis ulang	Anda ingin branch sebagai rangkaian linier yang bersih
git revert <sha>	Kebalikan dari sebuah commit	Menambah commit undo	Commit yang sudah mendarat harus dibatalkan di riwayat bersama

Aturan satu barisnya: cherry-pick memindahkan pilihan; merge dan rebase memindahkan semuanya. Mengulurkan tangan ke cherry-pick untuk “sinkronisasi” dengan sebuah branch adalah tanda Anda sebenarnya ingin merge — dan jika yang bersanding adalah main fork Anda melawan upstream, rutinitas lengkapnya ada di sinkronkan fork dengan upstream, langkah demi langkah.

Satu kebiasaan yang sebaiknya dilewati: memetik commit yang sama ke beberapa branch dalam jangka panjang. Setiap perbaikan berikutnya di branch sumber butuh pick baru, dan pada akhirnya branch-branch itu saling menjauh. Backport ke release branch adalah pola yang normal; alam paralel permanen bukan.

Alur kerja cherry-pick, ringkasnya

git log <source-branch> --oneline -5   # temukan SHA-nya
git switch <target-branch>             # mendarat di tempat yang benar
git cherry-pick A^..B                  # rentang, daftar, atau SHA tunggal
# saat konflik: selesaikan → git add → git cherry-pick --continue
git log -1 --stat                      # konfirmasi apa yang mendarat

Temukan, pindah, petik, verifikasi. Perintah ini punya reputasi berbahaya yang tidak ia layaki — diff-nya akan diterapkan, atau ia berhenti dan memberi tahu Anda kenapa. Kesalahan yang benar-benar destruktif satu-satunya adalah memetik ke branch yang salah, dan git log -1 sebelum push membuat yang itu sulit terlewat.