Git'te çakışma (merge conflict) nasıl çözülür, adım adım

Çakışma neden olur?

Git dalları birleştirirken değişiklikleri satır düzeyinde karşılaştırır. Aynı dosyanın farklı bölgelerini değiştirdiyseniz otomatik birleştirir. Ancak aynı satırları taraflar da değiştirdiyse ya da bir taraf dosyayı silerken diğeri düzenlediyse hangi sürümün doğru olduğuna karar veremez ve çakışma bildirir. Çakışma bir hata değil, Git'in insandan karar istemesidir.

Çakışma merge'e özgü değildir; rebase, cherry-pick ve stash pop sırasında da çıkabilir. Hepsinde mantık aynıdır: Git otomatik çözemediği dosyaları işaretler, siz karar verir, işlemi sürdürürsünüz. Çakışma çıktığında paniğe gerek yoktur; çünkü işlem yarıda durur ve dosyalarınız güvendedir. İstediğiniz an işlemi iptal edebilirsiniz.

Çakışma işaretlerini nasıl okursunuz?

Birleştirme çakışma ile durduğunda git status "unmerged paths" altında çakışan dosyaları listeler. Dosyayı açtığınızda Git şu işaretleri koymuştur:

<<<<<<< HEAD bulunduğunuz daldaki sürüm ======= birleştirdiğiniz daldaki sürüm >>>>>>> feature/odeme-ekrani

İlk işaretle ayraç arası mevcut dalınızdaki hâli, ayraçla son işaret arası gelen dalın hâlini gösterir. Rebase sırasında roller tersine döner: HEAD tarafı, üzerine yeniden uyguladığınız hedef dalı, gelen taraf ise sizin işlemenizi temsil eder. Bu karışıklık yüzünden rebase çakışmalarında ne seçtiğinizi dikkatle kontrol edin.

Git status çıktısında hangi dosyanın taraflarda da değiştirildiğini (both modified), hangisinin bir tarafta silindiğini görebilirsiniz. Önce hangi türde çakışma olduğunu anlamak çözüm yolunu belirler.

Çakışmayı elle çözmenin adımları

Adımlar şöyledir:

• git status ile çakışan dosyaları belirleyin
• Dosyayı açın, işaretlerin bulunduğu bölgeyi bulun
• Sürümleri okuyun ve nihai metni yazın: birini seçin, diğerini seçin ya da ikisini birlikte harmanlayın
• Çakışma işaret satırlarını (başlangıç, ayraç, bitiş) tamamen silin
• Dosyayı kaydedin ve derleyip çalıştırın ya da testleri koşturun
• git add dosya ile dosyayı çözülmüş olarak işaretleyin
• Merge ise git commit, rebase ise git rebase --continue ile sürdürün

Dikkat edilecek nokta, işaretlerin yanlışlıkla dosyada kalmasıdır. Bunu önlemek için commit öncesi arama yapın ya da ekibin ön commit denetiminde işaret metnini arayan bir kural kullanın. Sürümleri yalnızca metin olarak değil, davranış olarak da düşünün: taraflar aynı fonksiyonu farklı amaçla değiştirdiyse doğru çözüm bazen ikisini de yeniden yazmaktır.

Bir tarafı tümden seçmek: ours ve theirs

Bazen bir dosyada tek tarafın sürümünü olduğu gibi almak istersiniz; örneğin otomatik üretilmiş bir kilit dosyası ya da yapılandırma dosyası. Bu durumda git checkout --ours dosya ya da git checkout --theirs dosya komutu o tarafın sürümünü dosyaya yazar, ardından git add ile işaretlenir.

Burada "ours" ve "theirs" merge sırasında sırasıyla bulunduğunuz dal ve gelen daldır. Rebase sırasında ise tersine çevrilir: ours üzerine yeniden uyguladığınız hedef dalı, theirs sizin işlemenizi ifade eder. Yanlış tarafı seçmek yaygın bir hatadır; seçimden sonra git diff ile sonucun beklediğiniz olduğunu doğrulayın.

Tüm birleştirme için bir strateji seçeneği de vardır, ancak bu, çakışmayan değişiklikleri de etkileyebilir ve genellikle yalnızca tek bir dosya için bilinçli karar verildiğinde kullanılmalıdır.

Mergetool ve düzenleyici desteği

Çakışmayı metin düzenleyicide okumak zor geliyorsa görsel bir araç kullanabilirsiniz. Yaygın kod düzenleyicileri çakışma bölgelerini renklendirir ve "mevcut değişikliği kabul et", "gelen değişikliği kabul et" ya da "ikisini de kabul et" bağlantıları sunar. git mergetool komutu ise yapılandırdığınız birleştirme aracını açıp bölmeli bir görünüm gösterir: yerel sürüm, uzak sürüm ve ortak atadaki hâl.

Ortak atayı da gösteren görünümün asıl faydası ortak atadır. Hangi tarafın neyi neden değiştirdiğini ata sürümle karşılaştırarak görürsünüz; bu da karar vermeyi kolaylaştırır. Araç sonuç dosyasını kaydettiğinde yine git add ile işaretleme yapılması gerekir. Mergetool'un oluşturduğu yedek dosyaları (genellikle .orig uzantılı) commit'e karışmasın diye ignore kurallarına eklenir.

Vazgeçmek ve çözüm sonrası doğrulama

Çözümün ortasında yolu yanlış bulduysanız işlemi iptal edebilirsiniz: git merge --abort birleştirmeyi başlamadan önceki duruma döndürür, git rebase --abort aynısını rebase için yapar. Çalışma dizininizde kaydedilmemiş değişiklik varsa iptalin bunları etkileyebileceğini unutmayın; birleştirmeye başlamadan önce çalışma dizinini temiz tutun.

Çözümden sonra mutlaka doğrulama yapın: proje derleniyor mu, testler geçiyor mu, çakışan dosyada işaret satırı kaldı mı. Büyük çakışmalarda ilgili değişiklikleri yazanlara sormak, çözümü yalnız başınıza yorumlamaktan iyidir. Birleştirme işlemesinin mesajında çakışmanın hangi dosyalarda olduğu ve nasıl çözüldüğü kısaca yazılırsa sonradan inceleyen kişi neden bu karara varıldığını anlayabilir.

Çakışmayı önleme alışkanlıkları

Çakışmaların çoğu uzun yaşayan dallardan kaynaklanır. Dalı ne kadar uzun açık tutarsanız ana dal o kadar uzaklaşır. Küçük ve sık birleştirilen dallar, ana dalı düzenli olarak kendi dalınıza çekmek ve büyük dosyaları aynı anda başkasının da düzenlediğini ekip içinde duyurmak çakışmayı azaltır.

Teknik önlemler de yardımcı olur: kod biçimlendirici ve satır sonu kurallarının ekipçe ortak kullanılması gereksiz satır farklarını engeller, büyük dosyaların küçük modüllere bölünmesi aynı satırlarda yarışma ihtimalini düşürür. Aynı çakışmayı tekrar tekrar çözmek zorunda kalıyorsanız Git'in rerere özelliği, daha önce çözdüğünüz çakışma çözümünü hatırlayıp yeniden uygulayabilir. Bu özelliği devreye almadan önce çözümlerin doğruluğundan emin olun; yanlış bir çözüm de tekrarlanır.

Bu beceri Mindset programlarında nerede çalışılır?

Mindset'in GIT ve GITHUB Uzmanlığı Eğitimi, Git'e giriş ve temel kavramlar, branch yönetimi ve merge işlemleri, GitHub ile iş birliği, ileri düzey Git teknikleri ve açık kaynak katkı süreçlerini içerir. Çakışma çözümü, branch yönetimi ve merge işlemleri ile iş birliği başlıklarının günlük pratiğe dönüşen kısmıdır ve ekip içinde çalışmaya yeni başlayan geliştiriciler ve QA, DevOps gibi kod deposuyla temas eden roller için uygundur.

Kurumsal ekipler için ortak bir çakışma çözme alışkanlığı oluşturmak, birleştirme sırasında oluşan gecikme ve hataları azaltmanın pratik bir yoludur.