Git merge conflict nasıl çözülür? Adım adım çakışma çözme rehberi

Kısa yanıt

Git merge conflict, iki farklı dal aynı dosyanın aynı satırını çelişkili biçimde değiştirdiğinde meydana gelir. Terminalde git status komutunu çalıştırarak çakışan dosyaları tespit edebilir, ayırıcı işaretlerin arasındaki doğru kodları seçip fazlalıkları temizledikten sonra git add ve git commit adımlarıyla birleştirmeyi güvenle tamamlayabilirsiniz. Şüpheli anlarda commit öncesinde testleri mutlaka çalıştırmalısınız.

İşletim sistemi veya kod editörü ne olursa olsun arkadaki mekanizma asla değişmez, farklılaşan tek unsur kod bloklarını ekranda gördüğünüz arayüz tasarımıdır.

Merge conflict nedir ve neden oluşur?

Ekipler aynı kod tabanı üzerinde birbirinden bağımsız geliştirme dallarıyla çalışırken, Git arka planda değişikliklerin çok büyük bir bölümünü geliştiriciye hissettirmeden harmanlar. İki farklı kolda çalışan yazılımcılar aynı dosyanın tastamam aynı satırını çelişkili biçimde düzenlediklerinde ya da bir taraf dosyanın içeriğini güncellerken diğeri o dosyayı projeden sildiğinde, sistem hangi adımın geçerli olduğunu kendi kendine seçemez. Otomatik karar mekanizması devre dışı kaldığı anda süreç aniden durur, yerini bekleyen bir çakışma durumuna bırakır.

Bu kilitlenme hali sistemin çöktüğü veya bir hata verdiği anlamına gelmez, aksine sürüm kontrol mimarisinin bilinçli bir güvenlik bariyeridir. Durumun mantığını ayrıntılarıyla aktaran Git’in resmî kitabına göz attığınızda, sistemin yalnızca matematiksel olarak kesin kabul ettiği değişiklikleri otomatik birleştirdiğini görebilirsiniz. Ortada en ufak bir belirsizlik belirdiğinde kör bir varsayımda bulunup veriyi riske atmaz, inisiyatifi ve son onay hakkını projeyi inşa eden geliştiricinin kendisine devreder. Her merge conflict uyarısı, sistemin projenizi hatalı bir kod kabusundan korumak adına devreye soktuğu kontrollü bir frendir.

Ekiplerde en çok karşılaşılan senaryoların başında, iki kişinin aynı kurumsal iş mantığı fonksiyonuna veya merkezi konfigürasyon dosyasına aynı anda dokunması gelir. Ana daldan haftalar önce koparılmış ve güncellenmeyen bir geliştirme kolunu projenin omurgasına taşımaya çalışmak da benzer sancıları tetikler. Otomatik kod düzenleyicilerin ekip genelinde ortak bir standarta bağlanmaması yüzünden tek bir tuşla binlerce satırın girintisini değiştirmek ya da silinmiş bir bileşene başka bir kolda yeni referanslar eklemek, iş mantığı değişmese dahi birleştirme sürecini anında kilitler.

git status ile çakışan dosyaları bulma

Geliştirme dalını ana gövdeye bağlamak için birleştirme komutunu verdiğinizde terminal penceresinde ilk uyarı sinyali görünür:

Auto-merging src/app.js
CONFLICT (content): Merge conflict in src/app.js
Automatic merge failed; fix conflicts and then commit the result.

Hızlıca akıp giden terminal satırları arasında hangi varlıkların kilitlendiğini gözle aramaya çalışmak yerine, depodaki güncel tabloyu doğrudan git status komutuyla okumak çok daha net ve organize bir görünüm kazandırır:

$ git status
On branch feature/odeme-formu
You have unmerged paths.
 (fix conflicts and run "git commit")

Unmerged paths:
 (use "git add <file>..." to mark resolution)
 both modified: src/app.js
 both modified: src/config.json

Terminal çıktısında listenin başında yer alan both modified ibaresi, iki geliştirme kolunun da ilgili dosya üzerinde hak iddia ettiğini ve otomatik birleştirmenin tıkandığını açıkça ifade eder. Büyük çaplı sürümlerde veya uzun süredir bekleyen projelerde onlarca dosya aynı anda bu duruma düşebilir. Kod bloklarının arasına dalıp değişiklikleri düzenlemeye başlamadan önce listeyi eksiksizce gözden geçirmek, gözden kaçabilecek gizli bir çatışmayı önlemek bakımından hayati öneme sahiptir.

Çakışma işaretlerini okuma

Sürüm kontrol motoru, uzlaşmazlığın yaşandığı dosyaların içine geliştiricinin kolayca tespit edebileceği özel ayrım işaretleri ekler. İki farklı daldan beslenen satırlar dosya açıldığında şu biçimde görünür:

<<<<<<< HEAD
Const KDV_ORANI = 0.20;
=======
Const KDV_ORANI = 0.18;
>>>>>>> feature/vergi-guncelleme

Dosyaya yerleşen bu işaretleme bloğu temelde üç farklı bölgeden meydana gelir. En üstteki <<<<<<< HEAD etiketi ile ortadaki ======= çizgisi arasında kalan alan, şu an üzerinde çalıştığınız aktif dalın yerel kodunu doğrudan temsil eder. Orta ayrım çizgisi ile dipteki >>>>>>> dal-adı arasındaki kısım ise hedef daldan içeri çekmeye çalıştığınız harici değişiklikleri barındırır. En altta görünen dal etiketi, ilgili kod parçasının hangi geliştirme hattından taşındığını göstererek gerekirse kodu üreten ekip arkadaşınızla hızlıca iletişim kurabilmenize imkan tanır.

Çözümün mantığı gereksiz kalıntıları ayıklamaktan ibarettir; bu üç kontrol satırını dosyadan tamamen silip projenin çalışması gereken son halini yalın biçimde bırakmalısınız. Doğru hamle bazen iki tarafın yazdığı satırları alt alta korumayı, bazen iki yaklaşımı mantıksal bir süzgeçten geçirip birleştirmeyi, kimi zaman da iki öneriyi birden çöpe atıp sıfırdan üçüncü bir algoritma kurmayı gerektirebilir. Git bu aşamada içeriğin işlevsel doğruluğuna karışmaz, bütün sorumluluğu dosyayı düzenleyen programcının tercihine bırakır.

Git merge conflict nasıl çözülür? Adım adım

Kullandığınız metin düzenleyici ya da işletim sistemi ne olursa olsun, birleştirme çatışmalarını yönetirken izleyeceğiniz rota aynı değişmez kurallara dayanır. İlk olarak sorunlu dosyalar tespit edilir, kod blokları arasındaki çatışma işaretleri okunur, projenin mimarisine uygun kod seçilip ayırıcı etiketler silinir ve nihai dosya sahneye alınarak commit edilir.

Komut satırında çözüm

Süreci terminal üzerinden yürütüyorsanız git status komutundan dönen yanıt doğrultusunda ilgili dosyaları tespit edip favori metin düzenleyicinizde tek tek açmanız gerekir. Kod bloklarını inceleyip hangi satırların projede kalması gerektiğine karar verdikten ve Git tarafından eklenen ayırıcı işaretleri temizledikten sonra, ilgili dosyaları çözülmüş olarak damgalamak için sıradaki komutları işletmelisiniz:

Git add src/app.js
Git add src/config.json

Dosyaları sahne alanına ekleyerek çözümü onayladıktan sonra birleştirme sürecini tamamlayıp kalıcı bir kayıt haline getirmek için son hamleyi yaparsınız:

Git commit

Uygulama varsayılan olarak birleştirilen dalın ismini içeren hazır bir commit mesajı önerecektir, özel bir açıklama girmeyecekseniz bu mesajı doğrudan onaylayabilirsiniz. Çakışmalar içinden çıkılmaz bir hale büründüğünde ya da yanlış dala müdahale ettiğinizi anladığınızda paniğe kapılmanıza hiç gerek yoktur. Henüz son commit adımını atmadığınız müddetçe git merge --abort komutunu çalıştırarak çalışma alanınızı birleştirme işlemine başlamadan önceki tertemiz durumuna saniyeler içinde geri döndürebilirsiniz.

VS Code veya başka bir editörde çözüm

Gelişmiş arayüze sahip modern editörler dosya içindeki ham metin işaretlerini sizin yerinize şık ve tıklanabilir butonlara dönüştürerek süreci oldukça hızlandırır. Çakışmalı dosya editörde açıldığı anda ilgili blokların tepesinde “Current Change”, “Incoming Change” veya “Accept Both Changes” gibi yönlendirici seçenekler listelenir. Bu butonlara tıkladığınızda arayüz arka planda sizin yerinize o ayırıcı işaret satırlarını otomatik olarak siler ve tercih ettiğiniz kod bloğunu korur. Yüzlerce satırdan oluşan karmaşık dosyalarda görsel arayüzler hata payını ciddi oranda düşürür, ufak tefek birkaç satırlık durumlarda ise terminalden hızlıca ilerlemek çok daha pratiktir. Hangi geliştirme aracını tercih ederseniz edin, dosya içinde hiçbir ayırıcı işaret kalmadığından emin olmadan dosyayı sahneye almak, derleme anına kadar gizlenebilen riskli bir dikkatsizliktir.

Kilit dosyalarda ve binary dosyalarda merge conflict

Otomatik oluşturulan package-lock.json, yarn.lock ya da composer.lock gibi bağımlılık kilit dosyalarında patlak veren uyuşmazlıkları satır satır el yordamıyla çözmeye kalkışmamalısınız. Bu tür dosyalarda en sağlıklı yöntem, çakışan kilit dosyasını doğrudan silmek ve ardından npm install ya da yarn install gibi komutları yeniden çalıştırarak bağımlılık ağacının baştan kurulmasını sağlamaktır. Görseller, derlenmiş kütüphaneler veya medya varlıkları gibi binary dosyalarda ise Git metin tabanlı ayrım işaretleri ekleyemez. İki taraftan hangi sürümün yaşamaya devam etmesi gerektiğini seçerek git checkout --ours <dosya> ya da git checkout --theirs <dosya> komutlarından biriyle tercihinizi yapıp ardından dosyayı git add ile sahneye taşımalısınız.

GitHub’da pull request içinde merge conflict çözme

Bir pull request incelemesi sırasında çakışma uyarısı ile karşılaştığınızda önünüzde iki temel seçenek bulunur. Sorun yalnızca tek bir dosyayı ilgilendiriyorsa ve birkaç satırlık metin tabanlı basit bir yapıya sahipse, platformun sağladığı web düzenleyicisi işlemi tarayıcı üzerinden hızlıca halletmenize yarar. Bu arayüz çatışma işaretlerini ekrana getirir ve düzeltmeleri yaptıktan sonra yeni commit kaydını doğrudan web üzerinden oluşturmanıza imkan tanır. Sürecin teknik adımlarını merak ediyorsanız GitHub’ın resmî dokümantasyonu içindeki kılavuzlardan da faydalanabilirsiniz.

Çakışma projenin birden fazla kritik mimari dosyasına sıçramışsa veya binary varlıkları içeriyorsa web arayüzü çözüm üretmek için yetersiz kalacaktır. Bu tip senaryolarda ilgili dalı kendi yerel terminalinize çekerek çözümü geliştirme ortamınızda üretmek, ardından projeyi derleyip testleri koştuktan sonra uzak sunucuya göndermek her zaman daha güvenli bir yöntemdir. Kodu yerel ortamda ayağa kaldırıp çalıştırmadan sadece tarayıcı ekranındaki renkli satırlara bakarak seçim yapmak, yazım hatalarını ayıklasa bile uygulamanın sunucuda beklenmedik anlarda çökmesine neden olabilir.

Rebase sırasındaki merge conflict’ler merge’den nasıl farklıdır?

Rebase işleminde de aynı ayırıcı işaretler kullanılır ve dosyalar aynı el hareketleriyle temizlenir, fakat işlemin arka plandaki çalışma mekaniği klasik birleştirmeden bütünüyle ayrılır. Standart birleştirme operasyonunda bütün karmaşa tek bir zaman diliminde toplanır ve atılan tek bir commit ile nihai sonuca bağlanır. Rebase akışında ise sizin dalınızda biriken commit kayıtları, hedef dalın en güncel ucuna sırayla ve tek tek yeniden uygulanır. Bu durum, aynı problemli satırın her commit geçişinde birleştirme adımları boyunca tekrar tekrar önünüze gelmesine yol açabilir.

Sorunlu bloğu düzenledikten sonra git add komutuyla dosyayı sahneye almanız ve işlemi ilerletmek için git rebase --continue komutunu vermeniz gerekir. Akış içinden çıkılamaz bir karmaşaya sürüklenirse git rebase --abort komutunu çalıştırarak projenizi işlem öncesindeki güvenli noktaya geri taşıyabilirsiniz. Ekip arkadaşlarının ortak kullanımına açık genel paylaşımlı dallarda rebase uygulamak, commit geçmişini bütünüyle yeniden yazacağı için çalışma arkadaşlarınızın yerel depolarında ciddi karmaşalar doğurabilir. Karşılaşılabilecek risklerin yönetimi, ekibinizin benimsediği dağıtım ve sürüm stratejisiyle doğrudan bağlantılıdır. Kapsamlı DevOps rehberimizde üzerinde durduğumuz sık ve küçük parçalı teslimat felsefesi burada da en büyük güvencenizdir; ana hattan uzak kalma süresi uzadıkça geri dönüş yolundaki çakışma maliyeti katlanarak artar.

Merge conflict’leri önlemenin yolları

Çakışmaları tamamen ortadan kaldırmak ekip halindeki yazılım süreçlerinde gerçekçi bir beklenti değildir, ancak bazı sağlıklı çalışma alışkanlıkları kazanarak bunların sıklığını belirgin biçimde azaltabilirsiniz.

Geliştirme dallarını ana gövdeden uzun süre koparmadan, mümkün olduğunca kısa ömürlü tutarak izole kalma süresini asgariye indirmelisiniz. Üzerinde çalıştığınız dala belirli aralıklarla git pull veya git merge main uygulayarak ana koldaki güncellemeleri parça parça içeri almak birikmeyi önler. Dosya yapılarını ve modül sınırlarını küçük tutmak, birden fazla yazılımcının aynı kod parçasına müdahale etme olasılığını ciddi oranda zayıflatır. Benzer bileşenleri geliştiren ekip arkadaşlarıyla sürekli iletişim halinde kalarak planlanan mimari güncellemeleri erkenden paylaşmak sürprizleri engeller. Projedeki otomatik kod biçimlendirme kurallarını ortak bir konfigürasyon dosyası üzerinden sabitlemek, kişisel editör ayarlarından kaynaklanan anlamsız satır farklarının önüne geçer.

Sık yapılan hatalar

İşaretleme satırlarını dosya içinde unutarak kodu git add ile sahneye almak geliştiricilerin en sık düştüğü dikkatsizliklerden biridir. Gözden kaçan bu ayırıcılar sessizce derleme aşamasına veya doğrudan canlı ortama kadar sızıp beklenmedik çökmeler yaratabilir. Ne olduğunu tam olarak kavramadan sadece gelen tarafı ya da sadece kendi yazdığınız tarafı toptan seçmek de çakışmayı görünürde çözse bile çalışma arkadaşınızın kritik bir hata düzeltmesini tamamen yok edebilir.

Düzenleme işlemi tamamlandıktan sonra testleri çalıştırmamak veya projeyi yerelde derleyip ayağa kaldırmamak bozuk kodların depoya girmesine kapı aralar. İşlem tamamlanıp commit atıldıktan sonra git merge --abort komutunun hiçbir işe yaramayacağını her zaman aklınızda bulundurmalısınız. Projenizde benzer çakışmalar sürekli tekrarlanan kronik bir krize dönüştüyse, asıl problem dosyalardaki kodlardan ziyade ana koldan haftalarca ayrı kalan devasa geliştirme dallarıdır.

Kontrol listesi

Çakışma anlarında süreci sağlıklı yönetebilmek için adımları belirli bir disiplin içinde sırayla işletmek büyük kolaylık sağlar:

• Terminalde git status komutunu çalıştırarak kapsamı ve çatışma yaşayan tüm dosyaları netleştirin.
• Dosyalardaki işaretli blokları inceleyin ve hangi kodun kime ait olduğuna değil, iş mantığı açısından hangisinin doğru olduğuna odaklanın.
• Ayırıcı işaretlerin dosyadan tamamen silindiğinden emin olun ve değişiklikleri sahne alanına ekleyin.
• Kodları commit etmeden önce yerel ortamınızda testleri koşturup projenin sorunsuz derlendiğini doğrulayın.
• Yapılan tercihin nedenini ve hangi mantıkla çözüldüğünü net biçimde özetleyen açıklayıcı bir commit mesajı yazarak işlemi tamamlayın.

Sonraki adım

Merge conflict süreçleri, yazılım ekipleri genişledikçe ve geliştirilen projenin hacmi büyüdükçe günlük operasyonun son derece doğal bir parçası haline gelir. Panikle hareket etmeden kontrol adımlarını disiplinle işletmek olası aksaklıkları çok kısa sürede bertaraf eder. Dosyaları doğru komutlarla listelemek, satırları mantık süzgecinden geçirmek ve test edilmemiş kodu depoya göndermemek işin en temel prensibidir. Kurumsal dal yönetimini ve dağıtım süreçlerini profesyonel bir çerçevede tasarlamak için kurumsal web tasarım süreçleri rehberimize başvurabilirsiniz.

Sürüm kontrol akışlarınızı, dal mimarinizi ve yazılım yaşam döngünüzü optimize etmek isterseniz kurumsal yazılım çözümlerimize göz atabilir veya doğrudan bizimle iletişime geçebilirsiniz. Grup şirketimiz Web Tasarım Ofisi, web projelerinde sürüm kontrol altyapıları ve operasyonel bakım aşamalarında profesyonel destek sağlamaktadır.

İlgili rehberler

• Özel yazılım geliştirme