Cherry-pick — nedir, mekanizması ve Git’te uygulanması

Cherry-pick nedir?

Cherry-pick, belirtilen bir commit’teki değişiklikleri kopyalayan ve bunları geçerli dala yeni bir commit olarak uygulayan bir Git komutudur. İsim “kiş seçme” metaforundan gelir: geliştirici yalnızca ihtiyaç duyduğu commit’leri seçer, gerisini görmezden gelir.

Merge’den farklı olarak cherry-pick bir birleştirme commit’i oluşturmaz ve dalların tamamen birleştirilmesini gerektirmez. Rebase’den farklı olarak cherry-pick bir dizi commit’i aktarmaz — yalnızca belirtilenleri aktarır. Bu, cherry-pick’i düzeltmelerin hedefli aktarımı için ideal bir araç haline getirir.

Atlassian, 2025’e göre cherry-pick, aynı anda birden fazla sürüm dalıyla çalışan ekiplerin %47’si tarafından kullanılmaktadır. Cherry-pick özellikle mobil geliştirmede talep görmektedir; burada bir uygulamanın birden fazla sürümü (LTS sürümleri) aynı anda bakımı yapılır ve aralarında düzeltme aktarımı gerekir.

Aktarım mekanizması

Cherry-pick çalıştırıldığında Git, belirtilen commit ile onun ebeveyni arasındaki diff’i hesaplar, ardından bu diff’i geçerli dala uygular. Değişiklikler çakışma olmadan uygulanırsa — Git aynı mesajla ancak yeni bir SHA ile yeni bir commit oluşturur. Çakışma varsa — cherry-pick manuel çözüm için durur.

Cherry-pick nasıl çalışır

Sözdizimi basittir: aktarılacak commit’in hash’ini belirtin. Git değişiklikleri geçerli dala yeni bir commit olarak kopyalar. Aynı anda birden fazla commit ve tam aralıkların aktarımı desteklenir.

# Geçerli dala tek bir commit aktar
git cherry-pick a1b2c3d4

# Birden fazla commit aktar
git cherry-pick a1b2c3d4 e5f6g7h8

# Bir dizi commit’i aktar (a1b2’den f9e8’e, a1b2 hariç)
git cherry-pick a1b2c3d4..f9e8d7c6

Cherry-pick yürütüldükten sonra geçerli dal, kaynaktaki değişikliklerle birlikte yeni bir commit alır. Commit mesajı varsayılan olarak kaynaktan kopyalanır, ancak -n bayrağı (commit oluşturma) veya --edit (mesajı düzenle) ile değiştirilebilir.

Bir düzeltmenin aktarılması örneği

Tipik bir senaryo düşünelim: develop’da kritik bir hata bulunup düzeltildi ve bu hata sürüm dalı release/v2.0’da da mevcut. Tüm develop’ı sürüm dalına birleştirmeden yalnızca bu düzeltmenin aktarılması gerekiyor.

# develop’da düzeltme içeren commit hash’ini bul
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Sürüm dalına geç
git checkout release/v2.0

# Düzeltmeyi uygula
git cherry-pick a1b2c3d4

# Çakışma varsa — çöz ve devam et
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

-x bayrağı, commit mesajına orijinal SHA’ya bir referans ekler: “(cherry picked from commit a1b2c3d4)”. Bu, commit’in nereden aktarıldığını takip etmeyi kolaylaştırır. Geçici taslaklar dışındaki tüm senaryolarda -x kullanılması önerilir.

Çakışmalarla çalışma

Çakışma durumunda cherry-pick merge gibi davranır: Git durur ve çakışan dosyaları işaretler. Geliştirici çakışmayı çözer, git add’i çalıştırır ve ardından git cherry-pick --continue’u yürütür. İptal etmek için — git cherry-pick --abort. --strategy bayrağı, bir birleştirme stratejisi belirtmeye izin verir (örneğin, seçeneklerle recursive).

# Cherry-pick sırasında çakışma çözümü
# Git çakışan dosyaları gösterir
git status

# Manuel çöz, ardından:
git add izinli_dosya.kt
git cherry-pick --continue

# Veya cherry-pick’i iptal et:
git cherry-pick --abort

Cherry-pick ne zaman kullanılır

Cherry-pick, tüm dalları birleştirmeden değişikliklerin hedefli olarak aktarılmasının gerektiği senaryolarda idealdir. Cherry-pick’in en iyi seçim olduğu beş ana durumu inceleyelim.

• Hotfix aktarımı — develop’da bir düzeltme bulundu, ancak sürüm dalına (release/v2.0) uygulanması gerekiyor. Cherry-pick, develop’daki tamamlanmamış özellikleri etkilemeden yalnızca düzeltme commit’ini aktarır
• Eski sürümlere geri taşıma — mevcut sürüm için bir düzeltmenin LTS sürümüne aktarılması gerekiyor. Tüm mevcut kod tabanını birleştirmek yerine cherry-pick yalnızca gerekli commit’leri seçer
• Yanlış daldaki commit’i geri alma — bir commit yanlış dala yapıldıysa, cherry-pick onu doğru dala aktarır ve orijinal commit geri alınır
• Dokümantasyon aktarımı — tüm dallarda bulunması gereken README veya yapılandırma dosyalarındaki değişiklikler cherry-pick ile aktarmak için uygundur
• Seçici uygulama — bir prototip dalından, tüm prototipi ana geliştirmeye aktarmadan yalnızca başarılı bir commit alınması gerekir

Mobil geliştirme için cherry-pick, bir uygulamanın birden fazla sürümünü desteklerken kritik öneme sahiptir. Örneğin, Google Play’de yayınlanmış 3.2 sürümünde bir hata bulunursa ve develop 4.0 sürümü için kod içeriyorsa — cherry-pick, tüm kırılma değişikliklerini birleştirmeden v3.x dalına düzeltmeyi aktarmaya olanak tanır. Bu, farklı API’ler ve bağımlılıklarla iki veya daha fazla ana sürümün aynı anda bakımının yapıldığı projeler için özellikle önemlidir.

Pratik örnek: bir mobil uygulamada Android 12’de Google Sign-In ile kimlik doğrulama sırasında bir çökme tespit edildi. Düzeltme develop’da yapıldı ve kod incelemesinden geçti. Ancak mevcut sürüm dalı v2.5 zaten beta test aşamasında. Develop’dan release/v2.5’e düzeltme commit’inin Cherry-pick’i, henüz yayına hazır olmayan diğer değişiklikleri aktarmadan bir sonraki sürüme düzeltmeyi dahil etmeye olanak tanır.

Mobil projelerde cherry-pick kullanırken bağımlılıkları dikkate almak önemlidir: düzeltme, sürüm dalının ayrılma noktasından sonra develop’da değiştirilen dosyaları etkiliyorsa, cherry-pick eksik bir değişiklik seti getirebilir. Bu gibi durumlarda, ilgili tüm değişikliklerin de aktarıldığını doğrulamak gerekir, aksi takdirde uygulama derlenmeyebilir veya yanlış çalışabilir. Paylaşılan dala değişiklikleri göndermeden önce her zaman cherry-pick’ten sonra derlemeyi kontrol edin.

Cherry-pick vs Merge vs Rebase

Git’te değişiklikleri entegre etmek için üç ana araç — merge, rebase ve cherry-pick — farklı görevleri çözer. Seçim, ne kadar değişikliğin aktarılması gerektiğine ve geçmişin nasıl görünmesi gerektiğine bağlıdır.

Merge — iki dalı tamamen birleştirmeniz ve dallanma bilgilerini korumanız gerektiğinde. Rebase — temiz bir geçmişle kişisel bir dalı en son duruma güncellemeniz gerektiğinde. Cherry-pick — yalnızca bir commit veya birkaç seçilmiş commit’e ihtiyacınız olduğunda.

Pratikte bu araçlar birleştirilir: bir özellik develop üzerinde periyodik rebase ile geliştirilir, ardından --no-ff merge ile birleştirilir ve başka bir dala düzeltme aktarmak gerektiğinde cherry-pick kullanılır. Her araç kendi aşamasında kendi görevini çözer.

Cherry-pick riskleri ve sınırlamaları

Cherry-pick yararlı ancak yanlış veya aşırı kullanıldığında potansiyel olarak tehlikeli bir araçtır. Ana riskler, commit tekrarı, bağlam kaybı ve sonraki birleştirmeler sırasında çakışmalarla ilgilidir.

• Commit tekrarı — aynı commit daha sonra merge yoluyla dala girerse, Git değişikliklerde aynı olan ikinci bir commit oluşturur. Bu, geçmişi kirletir ve git bisect’i zorlaştırır
• Bağlam kaybı — cherry-pick diff’i aktarır ancak ebeveyn commit’ler ve bağımlılıklar hakkında bilgi aktarmaz. Cherry-pick, A’nın bağımlı olduğu B commit’i olmadan A commit’ini uyguladıysa, mantıksal hatalar oluşabilir
• Birleştirme çakışmaları — cherry-pick’ten sonra, tam dal birleştirmesi sırasında Git aynı değişiklikleri iki kez görebilir ve normal bir merge ile önlenebilecek çakışmalar oluşturabilir
• İzlenebilirlik eksikliği — -x bayrağı olmadan bir commit’in başka bir daldan aktarıldığını bilmek imkansızdır. Bir değişikliğin kaynağını araştırırken, bir geliştirici commit’in kökenini bulmak için saatler harcayabilir

Risk azaltma önerileri: orijinal SHA’yı belirtmek için her zaman -x bayrağını kullanın, commit mesajında cherry-pick nedenini belgeleyin ve mümkün olduğunda bağlam izin verdiğinde cherry-pick yerine merge kullanın. Cherry-pick’ler çoğalırsa — dalları yeniden yapılandırmayı düşünün.

Cherry-pick için otomatik kontroller

CI boru hatları cherry-pick’i ayrı bir senaryo olarak değerlendirmelidir. Otomatik bir kontrol kurulması önerilir: bir cherry-pick commit’i oluşturulduğunda, CI değiştirilen dosyaların beklenen kümeyle eşleştiğini doğrular ve etkilenen modüller için testler çalıştırır. Bu, dallar arasında değişiklik aktarırken regresyon riskini azaltır.