Git cherry-pick: çoklu commit, branch'ler, çakışmalar

TL;DR: git cherry-pick <sha>, herhangi bir branch’ten tek bir commit’i bulunduğunuz branch’e kopyalar — aynı yama, yeni SHA, taşınan history yok. Birden fazla commit için SHA’ları listeleyin ya da bir aralık kullanın (git cherry-pick A..B); aralığın A‘yı dışarıda bıraktığına dikkat edin, onu da dahil etmek için A^..B yazın. Çakışmada durursa çözün, git add yapın, git cherry-pick --continue çalıştırın. Cherry-pick belirli bir düzeltmeyi taşımak içindir — diğer branch’teki her şeyi istiyorsanız merge ya da rebase kullanın.

git cherry-pick aslında ne yapar?

Cherry-pick, var olan bir commit alır ve diff’ini bulunduğunuz branch’te yeni bir commit olarak uygular. Orijinal commit olduğu yerde kalır; kopya tertemiz bir SHA alır. Git hiçbir şeyi “taşımaz” — commit’in hâlâ eski branch’te görünmesine sonradan şaşıranlar, tam da bunu görüyor.

Bu kopyala-taşıma modeli, cherry-pick’in doğru araç olduğu anları belirler:

• Feature branch’teki tek bir düzeltmeye şimdi main üzerinde ihtiyacınız var, gerisini merge etmek yok.
• Yanlış branch’e commit’lenmiş bir hotfix, doğru branch’e inmek zorunda.
• Bir yama, main‘den asla merge almayan bir release branch’ine yeniden uygulanmak zorunda.

Tamamlayıcı beceri, sonradan yanlış olduğu anlaşılan bir commit’i geri almaktır — mekaniği git undo last commit: değişiklikleri koruyarak yazısında işleniyor.

Başka bir branch’ten commit nasıl cherry-pick edilir?

SHA’yı bulun, hedef branch’e geçin, alın:

# 1. Commit'i kaynak branch'te bulun
git log feature/payment-fix --oneline -5

# 2. Onu alacak branch'e geçin
git switch main

# 3. Kopyalayın
git cherry-pick 1a2b3c4

Bilinmeye değer iki kolaylık:

• git cherry-pick <branch>, o branch’in en tepesindeki commit’i alır — kullanışlıdır ama “en tepenin” ne olduğuna dair zihinsel modeliniz bayatlamışsa yanlışlıkla yapmak da kolaydır.
• Pick’ten sonra git log -1 --stat, neyin indiğini doğrular. Bir saniyelik okuma, bir revert kazandırır.

Commit’ler feature/payment-fix üzerinde kalır; o branch’i istediğiniz zaman silin — main‘deki kopyanın kendi SHA’sı vardır, eskisine bağımlılığı yoktur.

Birden fazla commit nasıl cherry-pick edilir?

Üç biçim, ne kadar sık isteyeceğiniz sırasıyla:

# 1. Açık liste — yazdığınız sırayla alınır
git cherry-pick 1a2b3c4 5d6e7f8

# 2. Aralık — A'dan sonraki her şey, B dahil
git cherry-pick A..B

# 3. A'yı da içeren aralık
git cherry-pick A^..B

A..B ile A^..B ayrımı klasik sürprizdir: A..B, A‘yı dışarıda bırakır. git log çıktısından aralığı görselleştirip en-eski..en-yeni alırsanız, en eski commit’i sessizce atlamış olursunuz. Hedefiniz “en eski birkaç commit, sırayla” ise en-eski^..en-yeni yazın; off-by-one kaybolur.

Birkaç pick’i üç ayrı commit yerine tek commit’e katmak için -n / --no-commit ile commit’siz stage’leyin, sonra tek seferde commit edin:

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

git cherry-pick neden çalışmıyor?

Dört gerçek sebep, sıklık sırasıyla:

1. Çakışma pick’i durdurdu. Git yamayı uygular, iki branch’te de değişmiş bir satıra gelir ve dizinin ortasında duraklar:

# dosyaları çözün, sonra:
git add <resolved-files>
git cherry-pick --continue   # ya da pick öncesi duruma dönmek için --abort

--continue opsiyonel değildir ve ima da edilmez — onu çalıştırana dek duraklamış bir cherry-pick dizisinin içindesiniz ve git status bunu söylemeye devam edecektir.

2. Pick boş (“The previous cherry-pick is now empty”). Değişiklik bu branch’te zaten vardır — çoğu zaman önceki bir pick’ten ya da squash’lanmış bir merge’den. git cherry-pick --skip ile atlayın ya da gerçekten işaretçiye ihtiyacınız varsa --allow-empty ile boş bir commit zorlayın.

3. Commit bir merge commit’idir. Merge’in iki ebeveyni vardır; “bu diff’i uygula” belirsizdir ve git tahmin yürütmek yerine reddeder. Hangi ebeveyne karşı diff aldığınızı söyleyin:

git cherry-pick -m 1 <merge-sha>   # parent 1 = merge'in *yapıldığı* branch

4. Yanlış working tree ya da detached HEAD. Pick, HEAD’in işaret ettiği yere iner. Pick’ten önce git branch --show-current; hiçbir şey basmıyorsa detached HEAD’desiniz ve branch değiştirdiğinizde commit yetim kalır.

Cherry-pick vs merge vs rebase: hangisi ne zaman?

Komut	Hedefe ne iner	History	Ne zaman kullanın
git cherry-pick <sha>	Yalnızca adı geçen commit(ler)	Kopya, yeni SHA’lar	Belirli bir düzeltmenin şimdi taşınması gerekiyorsa
git merge <branch>	Branch’teki her şey	Merge commit ya da fast-forward	Bütün branch’i, ayrışma görünür şekilde istiyorsanız
git rebase <base>	Branch’in tüm commit’leri, yeniden oynatılmış	Doğrusal, yeniden yazılmış SHA’lar	Branch’i temiz doğrusal bir dizi olarak istiyorsanız
git revert <sha>	Bir commit’in tersi	Geri alma commit’i ekler	Paylaşılan history’deki bir commit geri alınacaksa

Tek satırlık kural: cherry-pick bir seçkiyi taşır; merge ve rebase her şeyi taşır. Bir branch’le “senkronlaşmak” için cherry-pick’e uzanmak, aslında merge istediğinizin işaretidir — ve o branch, fork’unuzun main‘i karşısında upstream ise tam rutin, fork’u upstream ile adım adım senkronlama yazısında.

Atlanacak bir alışkanlık: aynı commit’i uzun vadeli birden çok branch’e cherry-pick’lemek. Kaynak branch’teki her gelecek düzeltme, yeni bir pick demektir ve branch’ler er geç ayrışır. Release branch’lerine backport normal bir desendir; kalıcı bir paralel evren değildir.

Cherry-pick iş akışı, özetle

git log <source-branch> --oneline -5   # SHA(ları) bulun
git switch <target-branch>             # doğru yere inin
git cherry-pick A^..B                  # aralık, liste ya da tek SHA
# çakışmada: çöz → git add → git cherry-pick --continue
git log -1 --stat                      # ne indiğini doğrulayın

Bul, geç, al, doğrula. Komut, hak etmediği bir tehlike şöhreti taşır — diff ya uygular ya da durur ve nedenini söyler. Gerçekten yıkıcı tek hata, yanlış branch’e almaktır; push’tan önce git log -1, o hatayı gözden kaçırmayı zorlaştırır.