Cherry-pick: nedir, nasıl yapılır ve Git komutları

Git’te cherry-pick nedir

Cherry-pick, mevcut bir commit’ten değişiklikleri alıp mevcut dala yeni bir commit olarak uygulayan git cherry-pick komutudur. Orijinal commit kendi dalında yerinde kalırken, hedef dalda değişikliklerin bir kopyası oluşturulur. Komut, tüm bir dalı taşımadan belirli bir düzeltmeyi aktarmanız gerektiğinde kullanışlıdır.

Sözdizimi: git cherry-pick <commit-hash>. Git, belirtilen commit’in ebeveynine göre farkını (diff) analiz eder ve bu farkı mevcut dala uygular. Birden çok dosya değiştirilirse, hepsi birlikte aktarılır. Komut ayrıca aralıkları da kabul eder: git cherry-pick A..B — A’dan B’ye kadar tüm commit’ler, A hariç.

Bayraklar yetenekleri genişletir: -n (--no-commit), commit oluşturmadan değişiklikleri çalışma dizinine ve indekse uygular — birden çok commit’in değişikliklerini birleştirmeniz gerektiğinde kullanışlıdır. -x bayrağı, commit mesajına bir satır (cherry picked from commit ...) ekleyerek geçmişteki değişikliklerin kaynağını izlemeyi kolaylaştırır.

# Hash ile tek bir commit’i cherry-pick yap
git cherry-pick a1b2c3d

# Birden çok commit’i cherry-pick yap (sırayla)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Otomatik commit olmadan cherry-pick yap
git cherry-pick -n a1b2c3d

# -x bayrağı orijinal commit’e referans ekler
git cherry-pick -x a1b2c3d

Cherry-pick ne zaman kullanılır

Ana senaryo, sürüm dalları arasında düzeltmelerin aktarılmasıdır. Şöyle düşünün: develop’da kritik bir hata bulundu ve düzeltildi. Sürüm dalı release/v2.1 zaten ayrılmış ve bu hatayı da içeriyor. Tüm develop’ı release’e birleştirmek birçok bitmemiş kod getirirken, tek düzeltme commit’ine cherry-pick uygulamak güvenli ve kesin bir çözümdür.

İkinci senaryo, değişiklikleri geri alıp sonra geri yüklemedir. Bir commit git revert ile geri alındıysa ve daha sonra geri almanın bir hata olduğu ortaya çıkarsa — geri alınan commit’e cherry-pick uygulamak değişiklikleri geri yükler. Bu, bir revert’i geri almaktan daha doğrudur çünkü tekrarlanan çakışmalar oluşturmaz.

Üçüncü senaryo, entegrasyon testi için farklı özellik dallarından commit’leri birleştirmedir. Birden çok bitmemiş dalı (tamamlanmamış kodla) birleştirmek yerine, her birinden yalnızca hazır commit’leri seçip birlikte nasıl çalıştıklarını test edebilirsiniz.

• Hata düzeltmeleri — bitmemiş kod olmadan develop’dan release’e düzeltme aktarma.
• Hotfix — bir hotfix dalından main ve develop’a aynı anda düzeltme uygulama.
• Hatalı revert’i geri alma — değişiklikleri geri yüklemek için geri alınan commit’e cherry-pick uygulama.
• Test — entegrasyon testi için farklı dallardan seçilmiş commit’leri toplama.

Cherry-pick vs rebase ve merge

Cherry-pick, tüm dallar yerine bireysel commit düzeyinde çalışmasıyla rebase ve merge’den ayrılır. rebase bir dalın tüm commit’lerini aktarır ve merge iki dalı birleştirirken, cherry-pick yalnızca gerekli olanları seçer. Bu, onu daha hassas bir araç yapar, ancak aynı zamanda daha manueldir.

Bir diğer fark ise yazarlıktır. Cherry-pick sırasında, Git varsayılan olarak orijinal commit’in yazarını korur, ancak committer geçerli kullanıcı olur. Commit mesajı, -x bayrağıyla kaynağı izleyebilir. rebase sırasında, hem yazar hem de committer yeni bir hash ile geçerli kullanıcı olur.

Performans: tek bir commit’e cherry-pick uygulamak, birçok commit’i olan iki dalı birleştirmekten daha hızlıdır. Ancak onlarca commit’i aktarmanız gerekiyorsa, geçici bir dal oluşturup rebase yapmak daha verimlidir ve onlarca hash belirtmeyi gerektirmez.

Birden çok commit aktarma

Birden çok commit, hash’lerini boşluklarla ayırarak tek bir komutla aktarılabilir: git cherry-pick A B C. Git, commit’leri belirtilen sırayla sırayla uygular. Herhangi bir commit çakışmaya neden olursa, cherry-pick duraklar ve geliştirici çakışmayı çözmeli, ardından git cherry-pick --continue ile devam etmelidir.

Commit aralığı: git cherry-pick A..B (A’dan sonra B’ye kadar tüm commit’ler, A hariç) ve git cherry-pick A^..B (A dahil B’ye kadar tüm commit’ler). Aralıklar, ebeveyn ilişkisi olmadan bir daldan tüm commit’leri aktarmanız gerektiğinde kullanışlıdır — örneğin, tamamlanmış bir özelliği eski bir daldan yeni bir dala taşırken.

--strategy bayrağı, Git’in değişiklikleri nasıl uygulayacağını belirler. Varsayılan olarak recursive stratejisi kullanılır, ancak çakışma tarafını otomatik olarak seçmek için ours veya theirs belirtebilirsiniz. --mainline bayrağı, bir merge commit’ine cherry-pick uygulanırken kullanılır — diff’in hesaplandığı ebeveyn numarasını (1 veya 2) belirtir.

# Cherry-pick commit aralığı
git cherry-pick develop~5..develop~2

# Merge commit’ini cherry-pick yap (ebeveyn belirt)
git cherry-pick -m 1 m9n0o1p

# theirs stratejisini kullan
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Çakışma çözümünden sonra devam et
git cherry-pick --continue

Cherry-pick sırasında çakışmalar

Cherry-pick sırasında çakışmalar, aktarılan commit’teki değişikliklerin hedef dalda değiştirilen aynı satırları etkilemesi durumunda ortaya çıkar. Git yürütmeyi duraklatır, çakışan dosyaları işaretler ve çözüm bekler. Durumda, bu dosyalar both modified olarak görünür.

Çakışma çözme adımları: çakışan dosyayı açın, çakışma işaretleyicilerini bulun (<<<<<<<, =======, >>>>>>>), içeriği düzenleyin, işaretleyicileri kaldırın, çözülen dosyalar için git add çalıştırın ve git cherry-pick --continue çalıştırın. Çakışma çözülemezse — git cherry-pick --abort tüm cherry-pick’i iptal eder ve dalı orijinal durumuna döndürür.

Yaygın bir sorun: commit zaten mevcut değişikliklere eşdeğer değişiklikler içeriyor. Bu durumda Git, cherry-pick denediğinde “nothing to commit” veya “empty commit” bildirir. --keep-redundant-commits ve --empty=keep bayrakları, Git’i sırayı korumak için boş bir commit oluşturmaya zorlarken, --skip böyle bir commit’i atlamayı sağlar.

# Cherry-pick sırasında çakışma — dur
git cherry-pick a1b2c3d
# error: a1b2c3d... commit mesajı uygulanamadı

# Çakışmayı çöz → indekse ekle
git add src/conflicted_file.swift
git cherry-pick --continue

# Boş commit’i atla (zaten uygulanmış)
git cherry-pick --skip

# Tam iptal
git cherry-pick --abort

Cherry-pick en iyi uygulamaları

İlk kural: aktarılan commit’in kendi kendine yeterli olduğunu her zaman doğrulayın. Commit A, aktarılmayan commit B’deki değişikliklere bağımlıysa, A’ya cherry-pick uygulamak derlemeyi bozabilir. Cherry-pick’ten önce, commit’in hangi dosyaları değiştirdiğini git show --stat <hash> ile kontrol etmek faydalıdır.

İkinci kural: cherry-pick işlemlerini belgeleyin. Commit mesajının orijinal commit’e bir referans tutması için -x bayrağını kullanın. Bu, daha sonraki geçmiş analizinde değişikliğin nereden geldiğini anlamaya yardımcı olur. -x olmadan, cherry-pick normal bir commit gibi görünür ve kaynağı yalnızca git log --graph ile belirlenebilir.

Üçüncü kural: çok fazla ayrışmış dallar arasında cherry-pick’ten kaçının. Commit oluşturulduktan sonra uzun zaman geçmiş ve kod tabanı önemli ölçüde değişmişse, çakışmalar çok sayıda ve karmaşık olacaktır. Bu gibi durumlarda, hedef dalda düzeltmeyi yeniden uygulamak daha iyidir — onlarca çakışmayı çözmekten daha az zaman alır.

• Cherry-pick yalnızca harici bağımlılıkları olmayan kendi kendine yeterli commit’ler.
• -x bayrağı, mesajda commit kaynağını belgelemek için zorunludur.
• Kaçının önemli kod tabanı farklılığı olan eski commit’lere cherry-pick uygulamaktan.
• CI/CD cherry-pick sonrası derlemeyi doğrulayın: çakışma olmamış olabilir, ancak kod derlenmeyebilir.
• PR yorumu pull request oluştururken cherry-pick ile hangi commit’lerin aktarıldığını belirtin.