Git Conflict Çözme ve Çakışma Sonrası Güvenli Çalışma Akışı

Git conflict çözme, iki farklı branch’te yapılan değişikliklerin Git tarafından güvenli biçimde otomatik birleştirilemediği durumda dosyanın hangi davranışı koruyacağına bilinçli olarak karar vermektir. İlk adım rastgele satır silmek veya doğrudan “ours” ya da “theirs” seçmek değil; mevcut durumu kayda almak, çakışan dosyaları incelemek ve değişikliklerin amacını karşılaştırmaktır.

Güvenli akış şu sırayla ilerler: incele, karşılaştır, düzenle, diff ile doğrula, test et. Bu yaklaşım, özellikle ekip reposuna ilk katkısını yapan geliştiricilerin değişiklik kaybı, yanlış dosyayı stage etme ve çalışmayan kodu commit etme riskini azaltır.

Git Conflict Neden Oluşur ve İlk Tepki Ne Olmalı?

Git conflict, iki branch’in aynı dosyada veya dosyanın aynı fonksiyon bölümünde birbiriyle otomatik olarak birleştirilemeyen değişiklikler taşımasıyla oluşur. Git, hangi satırın veya davranışın korunması gerektiğini her zaman anlayamaz. Bu durumda işlemi sessizce tamamlamak yerine çakışmayı geliştiricinin incelemesine bırakır.

Örneğin main branch’inde bir fonksiyon kullanıcı adını küçük harfe çevirirken, feature-validation branch’inde aynı fonksiyona boş değer kontrolü eklenmiş olsun. İki değişiklik aynı satır çevresinde yapıldıysa Git, bu iki yaklaşımın yalnızca birini mi seçmesi gerektiğini, yoksa ikisini birlikte mi uygulaması gerektiğini bilemez.

def normalize_username(username):
    return username.strip().lower()

Bir branch aynı fonksiyonu şu şekilde değiştirmiş olabilir:

def normalize_username(username):
    if not username:
        return ""
    return username.strip().lower()

Diğer branch ise giriş değerinin boşluklardan oluşup oluşmadığını kontrol etmiş olabilir:

def normalize_username(username):
    if not username.strip():
        return ""
    return username.strip().lower()

Her iki değişiklik aynı amaca, yani geçersiz kullanıcı adlarını ele almaya çalışsa da kontrol koşullarının davranışı farklıdır. username değeri None olabiliyorsa ikinci yaklaşım hata üretebilir; yalnızca boş metin kontrol edilecekse ilk yaklaşım yetersiz kalabilir. Çatışmayı çözmek, ekrandaki iki metin bloğundan birini seçmekten çok, fonksiyonun hangi girdileri kabul edeceğine karar vermektir.

git pull sırasında conflict neden görülebilir?

git pull genellikle uzak depodaki değişiklikleri alıp mevcut yerel branch ile birleştirme ihtiyacı doğurur. Yerel çalışma alanınızda değiştirdiğiniz satırlar ile uzak branch’ten gelen değişiklikler aynı bölgeyi etkiliyorsa Git birleştirmeyi tamamlayamayabilir.

Basit bir senaryoda ekip arkadaşınız config.py içindeki varsayılan ayarı değiştirirken siz de aynı satırı yerel branch’inizde değiştirmiş olabilirsiniz. Uzak değişiklikleri almaya çalıştığınızda Git iki farklı metinle karşılaşır. Bu metinlerin teknik olarak ikisi de geçerli olsa bile, birlikte hangi sonucun istenildiğini Git tek başına belirleyemez.

Bu noktada conflict oluşması, deponun bozulduğu veya yapılan tüm çalışmaların kaybolduğu anlamına gelmez. Daha doğru ifade şudur: Birleştirme işlemi duraklatılmıştır ve Git, çakışan bölümlerde insan kararı beklemektedir. Çözüm tamamlanana kadar çalışma alanındaki dosyalarda özel conflict marker satırları görülebilir.

git merge sırasında conflict ne anlatır?

git merge, bir branch’teki geçmişi başka bir branch’in mevcut geçmişiyle birleştirmeye çalışır. Örneğin feature-login branch’ini main branch’ine almak istediğinizde, iki branch’in ortak geçmişten sonra farklı dosya değişiklikleri içerdiği görülür.

git switch main
git merge feature-login

Bu komutların amacı, feature-login branch’indeki çalışmayı main ile birleştirmeyi denemektir. Çakışma yoksa Git işlemi tamamlayabilir. Çakışma varsa işlem yarıda kalır ve hangi dosyaların incelenmesi gerektiğine dair durum bilgisi üretir. Komutun riskli tarafı, merge işleminin mevcut çalışma alanını değiştirmesidir; bu nedenle komutu çalıştırmadan önce kaydedilmemiş yerel değişikliklerin durumunu kontrol etmek önemlidir.

İlk refleks ne olmalı?

Conflict gördüğünüz anda sakin kalın ve önce durumu gözlemleyin. Aşağıdaki yaklaşım, hangi dosyaların etkilendiğini ve çalışma alanında daha önceden bulunan değişikliklerin olup olmadığını anlamaya yardımcı olur:

1. İşlemi durdurup ekrana bakın: Git’in hangi birleştirme işleminde olduğunu ve hangi dosyaları işaretlediğini anlamaya çalışın.
2. Durumu kayda alın: Terminal çıktısını kopyalayabilir, gerekiyorsa mevcut dosyanın yedeğini alabilir veya değişiklikleri ayrı bir klasörde saklayabilirsiniz.
3. Çakışan dosyaları listeleyin: Dosyaları görmeden tüm projede rastgele düzenleme yapmayın.
4. Değişikliklerin amacını karşılaştırın: Bir branch’in neden değiştirildiğini, diğer branch’in hangi problemi çözdüğünü anlamaya çalışın.
5. Dosyayı düzenleyin: Yalnızca metni temizlemekle yetinmeyin; fonksiyonun beklenen davranışını koruyun.
6. Diff ile doğrulayın ve test edin: Stage öncesi ve sonrası farkları kontrol edin, ardından ilgili testleri çalıştırın.

Rastgele dosya silmek, çakışan bölümü tamamen bir branch’in içeriğiyle değiştirmek veya ilk refleks olarak “ours” ya da “theirs” seçmek güvenli bir çözüm değildir. Bu seçenekler bazen doğru sonuca ulaşabilir; ancak hangi tarafın neden korunacağını anlamadan kullanıldığında diğer branch’teki gerekli iş mantığını silebilir.

Git kullanımının temel mantığını, branch geçmişini ve değişiklik karşılaştırmasını daha sistemli biçimde öğrenmek isteyenler için canlı yazılım eğitimleri içinde uygulamalı bir öğrenme yolu tercih edilebilir. Buradaki amaç komutları ezberlemek değil, her komutun çalışma alanında neyi değiştirdiğini öngörebilmektir.

Conflict Marker Satırları Nasıl Okunur?

Git bir çakışmayı dosyanın içine üç temel marker satırı yerleştirerek görünür hâle getirir. Bu satırlar kodun parçası değildir; Git’in iki değişiklik bloğunu size göstermesi için eklediği geçici işaretlerdir. Çözüm tamamlandığında bu marker satırlarının tamamı kaldırılmalıdır.

<<<<<<< HEAD
if username is None:
    return ""
=======
if not username.strip():
    return ""
>>>>>>> feature-validation

Bu örnekte marker’ların görevi şöyledir:

• <<<<<<< HEAD satırı, mevcut branch’in veya o anda üzerinde çalışılan tarafın değişiklik bloğunun başladığını gösterir.
• ======= satırı, iki değişiklik bloğunu birbirinden ayırır.
• >>>>>>> feature-validation satırı, birleştirilmeye çalışılan diğer branch tarafının bloğunun bittiğini gösterir.

Buradaki HEAD ifadesi mevcut çalışma noktasını, son marker’daki branch adı ise birleştirme işlemine dahil edilen diğer tarafı anlamanıza yardımcı olur. Marker’ın üzerindeki veya altındaki metnin her zaman “doğru” ya da “yanlış” olduğu sonucuna doğrudan varılamaz. Marker yalnızca Git’in iki farklı metni yan yana gösterdiğini anlatır.

Marker bloklarını okurken yalnızca satırlara bakmayın

Çakışan iki satırı karşılaştırırken şu dört soruyu sorun:

• Fonksiyon hangi girdileri kabul ediyor?
• Hangi çıktı sözleşmesi korunmalı?
• Fonksiyonun yan etkisi var mı; örneğin dosyaya yazıyor, kayıt oluşturuyor veya başka bir servisi çağırıyor mu?
• Bu fonksiyon projenin hangi bölümlerinden ve hangi varsayımlarla çağrılıyor?

Örneğin bir branch boş metni reddetmek, diğer branch ise None değerini güvenli biçimde ele almak istiyorsa, iki değişiklik bilinçli olarak birleştirilebilir. Burada amaç marker bloğunun üst veya alt tarafını seçmek değil, her iki iş kuralını da güvenli biçimde ifade etmektir.

def normalize_username(username):
    if username is None:
        return ""
    cleaned = username.strip()
    if not cleaned:
        return ""
    return cleaned.lower()

Bu çözümde önce None kontrol edilir, ardından baştaki ve sondaki boşluklar temizlenir. Temizlenmiş değer boşsa boş metin döndürülür; aksi durumda küçük harfe çevrilmiş sonuç üretilir. Böylece iki branch’in doğrulama niyeti, davranışları çelişmeden tek bir fonksiyonda birleştirilmiştir.

Bu örneğin önemli noktası, dosyanın marker’lardan arındırılmış görünmesinden ibaret değildir. Çözümün doğru sayılabilmesi için fonksiyonun çağrıldığı yerlerde boş metin döndürülmesinin beklenen davranış olup olmadığı da kontrol edilmelidir. Bazı projelerde boş değer döndürmek yerine hata fırlatmak, kullanıcıya mesaj göstermek veya işlemi durdurmak gerekebilir.

İki branch’in doğrulama koşulları nasıl karşılaştırılır?

Diyelim ki bir branch şu koşulu eklemiştir:

if not value:
    return None

Diğer branch ise şu kontrolü kullanmıştır:

if len(value.strip()) < 3:
    raise ValueError("Değer en az 3 karakter olmalı")

Bu iki yaklaşım aynı değildir. İlki boş veya “false” kabul edilen bir değeri sessizce None olarak döndürüyor olabilir. İkincisi ise uzunluk kuralını zorunlu tutarak hata fırlatır. Birleştirme kararı verirken şu durumları ayrı ayrı düşünmek gerekir:

• None geldiğinde ne yapılacağı,
• boş metin geldiğinde ne yapılacağı,
• yalnızca boşluklardan oluşan değerlerin kabul edilip edilmeyeceği,
• iki karakterlik gerçek bir değerin geçerli olup olmadığı,
• hatanın çağıran kod tarafından yakalanıp yakalanmadığı.

Bu nedenle “üstteki branch benim branch’im, onu bırakayım” veya “alttaki branch ekip arkadaşımın, onu alayım” mantığı tek başına yeterli değildir. Doğru seçim, kodun proje içindeki sözleşmesine ve kullanıcıdan beklenen girdiye göre yapılır.

Algoritmik düşünme, koşulların hangi sırayla çalışacağını ve farklı girdilerde nasıl sonuç üreteceğini değerlendirmeyi gerektirir. Bu konuda mevcut seviyesini ölçmek isteyen okuyucu, algoritma bilgi testi ile temel problem çözme yaklaşımını gözden geçirebilir.

Çakışan Dosyayı Adım Adım Güvenle Düzenleme

Çakışan dosyayı güvenli biçimde düzenlemek için önce Git’in hangi dosyaları sorunlu gördüğünü belirleyin. Bunun için kullanılan temel komut şudur:

git status

git status çalışma alanının ve staging alanının mevcut durumunu gösterir. Beklenen olarak merge işleminin devam ettiğine ve birleştirilememiş dosyalar bulunduğuna dair bilgiler görebilirsiniz; ancak ekrandaki kesin ifade, kullanılan Git arayüzüne ve çalışma biçimine göre farklı görünebilir. Bu komut dosyayı çözmez, yalnızca hangi noktada olduğunuzu anlamanızı sağlar.

1. Çakışan dosyaları belirleyin

Önce listelenen dosya adlarını tek tek not edin. Bir projede birden fazla dosya conflict durumunda olabilir. Sadece terminalde ilk gördüğünüz dosyayı düzenleyip işlemi tamamladığınızı varsaymayın.

Dosya listesini şu sorularla karşılaştırın:

• Bu dosyada benim yerel değişikliğim var mıydı?
• Birleştirdiğim branch bu dosyada hangi özelliği değiştirmiş?
• Dosyanın tamamında mı, yoksa yalnızca belirli bir fonksiyonda mı conflict bulunuyor?
• Dosyanın yanında test, yapılandırma veya dokümantasyon dosyaları da etkilenmiş mi?

2. Dosyayı açın ve marker bloklarını bulun

Çakışan dosyayı bir editörde açarak <<<<<<<, ======= ve >>>>>>> marker’larını arayın. Bir dosyada birden fazla marker bloğu bulunabilir. İlk bloğu düzenledikten sonra dosyanın geri kalanını da kontrol edin.

Marker’ların çevresindeki kodu da okuyun. Bir fonksiyonun yalnızca birkaç satırı çakışmış olsa bile, bu fonksiyonun üstündeki değişken tanımları, altındaki dönüş kodu veya çağrıldığı yerler çözümün doğruluğunu etkileyebilir.

3. İki branch’in niyetini karşılaştırın

Çözümden önce iki tarafın neyi değiştirdiğini anlamaya çalışın. Bir branch hata kontrolü eklemiş, diğeri performans amacıyla veri hazırlama adımını değiştirmiş olabilir. Bu iki değişiklik aynı satıra denk geldiğinde, yalnızca metinsel farkı değil, işlevsel amacı da incelemek gerekir.

Karşılaştırma yaparken şu karar çerçevesini kullanabilirsiniz:

1. Değişiklik hangi problemi çözmek için yapılmış?
2. Bu problem diğer branch’te ele alınmış mı?
3. İki davranış birlikte uygulanabilir mi?
4. Birleştirme sonrası beklenmeyen bir yan etki oluşur mu?
5. Bu davranışı doğrulayacak bir test veya örnek girdi var mı?

4. Kodu seçin veya bilinçli biçimde birleştirin

Üç olasılık vardır: mevcut branch’in kodunu korumak, diğer branch’in kodunu korumak veya iki yaklaşımı yeni ve tutarlı bir çözüm hâline getirmek. Üçüncü seçenek çoğu zaman en dikkatli incelemeyi gerektirir; çünkü iki kod parçasını arka arkaya eklemek otomatik olarak doğru bir davranış oluşturmaz.

Örneğin iki branch de aynı fonksiyona doğrulama eklediyse, koşulların sırasını inceleyin. Önce tür kontrolü mü yapılmalı, yoksa değer temizlenmeli mi? Hata durumunda fonksiyon boş değer mi döndürmeli, yoksa istisna mı fırlatmalı? Bu kararlar kodun okunabilirliğinden çok programın davranışını belirler.

5. Tüm marker’ları temizleyin ve dosyayı kaydedin

Çözüm seçildikten veya birleştirildikten sonra dosyada hiçbir conflict marker kalmamalıdır. Editörün arama özelliğiyle üç marker biçimini ayrı ayrı arayın. Marker kalması, programın sözdizimini bozabilir veya bazı durumlarda metnin yanlışlıkla kaynak koduna dahil olmasına yol açabilir.

Ancak marker’ları silmiş olmak, conflict’in doğru çözüldüğü anlamına gelmez. Örneğin aşağıdaki iki yaklaşım metinsel olarak temiz görünebilir:

def can_publish(title):
    return bool(title)

def can_publish(title):
    return len(title.strip()) >= 5

İlk çözüm boş olmayan tek karakterlik bir başlığı kabul eder. İkinci çözüm ise en az beş karakterlik, boşlukları temizlenmiş bir başlık bekler. Dosyada marker olmaması yalnızca birleştirmenin biçimsel kısmının tamamlandığını gösterir; ürün kuralının doğru uygulandığını göstermez.

6. Yalnızca doğru dosyayı stage edin

Dosyayı kaydettikten sonra Git’e çözümün tamamlandığını bildirmek için genellikle git add kullanılır:

git add src/username.py

Bu komutun anlamı “bu dosyadaki conflict’i çözdüm ve bir sonraki aşamaya geçirmek istiyorum” şeklindedir. git add, yazdığınız kodun doğru olduğunu, testlerin geçtiğini veya tüm gereksiz değişiklikleri temizlediğinizi kanıtlamaz.

Yanlış dosyayı stage etmemek için komuttan önce dosya adını git status çıktısıyla karşılaştırın. Birden fazla dosya üzerinde çalışıyorsanız hepsini tek seferde eklemek yerine, gerçekten kontrol ettiğiniz dosyaları dosya bazında stage etmek daha güvenli olabilir.

• Stage edeceğiniz dosyanın adını açıkça yazın.
• Yeni ve ilgisiz dosyaların listeye eklenmediğini kontrol edin.
• Çakışan tüm dosyaların çözülüp çözülmediğini yeniden gözden geçirin.
• Stage işleminden sonra git diff --cached ile hazırlanan değişikliği okuyun.

Bu aşamada en sık yapılan hata, git add . komutunu düşünmeden çalıştırmaktır. Bu komut bazı çalışma biçimlerinde mevcut klasördeki ilgisiz değişiklikleri de staging alanına taşıyabilir. Komutun kendisi yanlış değildir; ancak kapsamı kontrol edilmeden kullanıldığında yanlış dosyanın commit’e girmesi riskini artırır.

Metinsel temizlik ile davranış doğruluğunu ayırın

Güvenli çözüm için iki ayrı kontrol yapın. İlk kontrol metinseldir: marker’lar silinmiş mi, dosya sözdizimi bozulmuş mu, gereksiz satırlar kalmış mı? İkinci kontrol davranışsaldır: fonksiyon beklenen girdilerde doğru çıktıyı veriyor mu, hata durumları korunuyor mu, çağıran kodun varsayımları hâlâ geçerli mi?

Bu ayrım, “dosya artık temiz görünüyor” ile “program doğru çalışıyor” arasındaki farkı ortaya çıkarır. Çözüm akışının bu bölümündeki pratik kuralı şöyle uygulayın: incele, karşılaştır, düzenle, diff ile doğrula, test et. Stage etmek yalnızca bu sürecin bir adımıdır; son karar testlerden ve kodun beklenen davranışı karşılamasından sonra verilmelidir.

git diff ve git diff --cached ile Çözümü Doğrulama

Bir conflict dosyasını düzenledikten sonra “dosya artık düzgün görünüyor” demek, çözümün doğru olduğu anlamına gelmez. Güvenli akışta önce çalışma ağacındaki henüz stage edilmemiş değişiklikler git diff ile incelenir; ardından bilinçli olarak stage edilen içerik git diff --cached ile yeniden kontrol edilir.

Bu iki komut benzer görünse de farklı sorulara cevap verir. git diff, dosyada yaptığınız fakat henüz index’e, yani stage alanına almadığınız değişiklikleri gösterir. git diff --cached ise bir sonraki commit’e girmeye hazırladığınız içerikleri gösterir. Bu nedenle conflict çözümünde güvenilir sıra genellikle incele, karşılaştır, düzenle, diff ile doğrula, test et şeklindedir.

Stage öncesi denetim: git diff

Conflict marker satırlarını düzenledikten hemen sonra dosyayı stage etmek yerine önce aşağıdaki komutla değişiklikleri inceleyin:

git diff

Bu komut, çalışma ağacındaki değişiklikleri son commit’teki hâliyle karşılaştırır. Conflict çözümü sırasında dosyada henüz stage edilmemiş düzenlemeler varsa, yaptığınız birleşik çözümü burada görebilirsiniz.

Beklenen gözlem, yalnızca gerçekten çözmeye çalıştığınız dosyada ve ilgili fonksiyon veya kod bloğunda anlamlı bir değişiklik bulunmasıdır. Örneğin iki branch’in aynı doğrulama fonksiyonunu değiştirdiği bir durumda, diff çıktısında fonksiyonun yeni kontrol akışı görünmelidir. Dosyanın geri kalanında ilgisiz satırların değiştiğini görüyorsanız, editörün otomatik biçimlendirme yapmış olması veya yanlış dosyanın düzenlenmesi ihtimallerini araştırın.

git diff çıktısını incelerken özellikle şu hata işaretlerine bakın:

• Conflict çözümüyle ilgisi olmayan beklenmeyen bir dosya değişmiş mi?
• Başında - bulunan satırlar arasında yanlışlıkla silinmiş bir fonksiyon parçası var mı?
• <<<<<<<<, ======= veya >>>>>>> marker satırlarından biri hâlâ duruyor mu?
• İki branch’ten alınması gereken davranışlardan biri tamamen kaybolmuş mu?
• Girinti, parantez, blok kapanışı veya fonksiyon dönüş değeri bozulmuş mu?

Diff içinde bir satırın silinmiş olması tek başına hata değildir. Bazen conflict çözümü için eski bir kontrol kaldırılır. Önemli olan silinen satırın yerine gerekli davranışın başka bir biçimde korunup korunmadığıdır. Bu yüzden yalnızca renkli satırlara değil, değişikliğin iş mantığına da bakılmalıdır.

Bilinçli stage etme: git add ve git status

Diff incelemesi tamamlanmadan git add . kullanmak, farkında olmadığınız dosyaları da stage alanına taşıyabilir. Conflict sonrasında daha güvenli yaklaşım, yalnızca incelediğiniz dosyayı açıkça belirtmektir:

git add path/to/file
git status

Buradaki path/to/file ifadesi, çözdüğünüz gerçek dosya yoluyla değiştirilmelidir. git add dosyayı stage alanına alır; git status ise Git’in çalışma ağacını ve stage alanını nasıl gördüğünü tekrar gösterir.

git status çıktısında çözdüğünüz dosyanın staged değişiklikler arasında görünmesi beklenir. Bunun yanında ilgisiz bir dosya da stage edilmişse commit’e devam etmeyin. Önce bu dosyanın neden stage edildiğini araştırın. Gerekirse dosyayı stage alanından çıkarmak için şu komutu kullanabilirsiniz:

git restore --staged path/to/unwanted-file
git status

Bu işlem dosyadaki değişikliği silmez; yalnızca dosyayı commit hazırlığından çıkarır. Böylece dosyayı daha sonra ayrıca inceleyebilirsiniz. Ancak çalışma ağacındaki değişikliği kaldırmak için kullanılan komutlarla stage alanından çıkarmayı birbirine karıştırmamak gerekir. Özellikle geri dönüş amacıyla kullanılan komutları çalıştırmadan önce hangi alanı değiştireceğinizi kontrol edin.

Stage sonrası denetim: git diff --cached

Dosyayı stage ettikten sonra aynı dosyayı bir kez daha kontrol edin:

git diff --cached

Bu komut, stage alanındaki içerikle son commit arasındaki farkı gösterir. Başka bir ifadeyle, henüz commit oluşturulmamış olsa da commit’e gidecek değişikliği incelersiniz.

Stage öncesinde git diff ile doğru görünen bir çözümün, stage sonrasında beklediğiniz içerikle aynı olduğunu doğrulamak önemlidir. Örneğin bir dosyada birkaç farklı düzenleme yapıp yalnızca bir kısmını stage ettiyseniz, git diff ile git diff --cached farklı sonuçlar gösterebilir. Bu her zaman hata değildir; fakat hangi parçanın commit’e gideceğini bilmeden commit oluşturmak risklidir.

git diff --cached çıktısında şu sorulara cevap arayın:

• Commit’e gerçekten çözülmüş dosya mı gidiyor?
• Conflict marker satırları tamamen temizlenmiş mi?
• Yanlış branch’ten gelen ve bu birleşimde gerekmeyen bir değişiklik taşınmış mı?
• Fonksiyonun beklenen dönüş değerleri korunmuş mu?
• Gereksiz boşluk, biçimlendirme veya ilgisiz dosya değişikliği var mı?

Stage sonrası diff içinde hâlâ eski conflict marker’ları görüyorsanız commit oluşturmayın. Dosyayı yeniden açıp ilgili kod bloğunu düzenleyin, ardından tekrar git diff, git add ve git diff --cached sırasını uygulayın.

Stage öncesi ve stage sonrası karşılaştırma

Conflict çözümünü diff ile doğrulama kontrol listesi

• Conflict marker satırları tamamen kaldırıldı mı?
• Değişiklik doğru dosyada ve doğru fonksiyon içinde mi?
• İki yaklaşımın gerekli davranışı, bilinçli bir birleşik akışta korunuyor mu?
• İlgisiz veya gereksiz satırlar değişmiş mi?
• git diff çıktısı beklenen çalışma ağacı değişikliğini gösteriyor mu?
• git diff --cached çıktısı gerçekten commit etmek istediğiniz içeriği gösteriyor mu?
• git status içinde çözülmemiş veya yanlış stage edilmiş dosya kalmış mı?

Bu kontrol, otomatik olarak “ours” veya “theirs” seçmekten daha güvenlidir. Çünkü conflict çözümünün amacı bir tarafı körü körüne korumak değil, iki değişikliğin gerektirdiği davranışı doğru bir kod akışında birleştirmektir.

Çalışan Terminal Senaryosu: Aynı Fonksiyondaki Conflict'i Çözmek

Aşağıdaki senaryoda iki branch, aynı validate_username fonksiyonunu farklı amaçlarla değiştirir. İlk branch minimum uzunluk kuralı ekler; ikinci branch baştaki ve sondaki boşlukları temizler. İki değişiklik de aynı fonksiyonun aynı bölümüne dokunduğu için merge sırasında conflict oluşur.

1. Küçük projeyi oluşturma

Bu örnek Unix benzeri bir kabukta çalıştırılabilecek temel bir Python dosyası kullanır. Branch adları örneği anlaşılır kılmak için açıkça verilmiştir; kendi projenizdeki branch adları farklı olabilir.

mkdir git-conflict-demo
cd git-conflict-demo
git init
git branch -M base
git config user.name "Demo User"
git config user.email "[email protected]"
cat > validator.py <<'PY'
def validate_username(username):
    if not username:
        return "Kullanıcı adı gerekli"
    return "Geçerli"
PY
git add validator.py
git commit -m "Temel kullanıcı adı doğrulamasını ekle"

İlk commit, iki branch’in de ortak başlangıç noktasıdır. Böyle bir başlangıç oluşturmak conflict’in hangi değişikliklerden kaynaklandığını anlamayı kolaylaştırır.

2. İlk branch’te uzunluk kuralını değiştirme

git switch -c validation-rule
cat > validator.py <<'PY'
def validate_username(username):
    if not username:
        return "Kullanıcı adı gerekli"
    if len(username) < 3:
        return "Kullanıcı adı en az 3 karakter olmalı"
    return "Geçerli"
PY
git add validator.py
git commit -m "Kullanıcı adı uzunluk kuralını ekle"

Bu branch, boş değeri kontrol etmeye devam eder ve ayrıca üç karakterden kısa kullanıcı adlarını reddeder. Şimdi ortak başlangıç branch’ine dönüp farklı bir kural uygulayacağız.

3. İkinci branch’te aynı fonksiyonu farklı biçimde değiştirme

git switch base
git switch -c normalize-rule
cat > validator.py <<'PY'
def validate_username(username):
    username = username.strip()
    if not username:
        return "Kullanıcı adı boş bırakılamaz"
    return "Geçerli"
PY
git add validator.py
git commit -m "Kullanıcı adındaki boşlukları temizle"

Bu branch’te amaç, kullanıcının başına veya sonuna yanlışlıkla eklediği boşlukları temizlemektir. Ayrıca boş değer için hata mesajı da değiştirilmiştir. Henüz uzunluk kontrolü bu branch’te bulunmaz.

4. Merge ile conflict üretme

İki branch’in değişikliklerini birleştirmek için ilk branch’e geçip ikinci branch’i merge edelim:

git switch validation-rule
git merge normalize-rule
git status

Merge işlemi conflict ile durduğunda Git, çözüm bekleyen dosyayı status çıktısında belirtir. Ortam ve Git ayarlarına göre mesajların biçimi değişebilir; önemli olan dosyanın çözülmemiş conflict olarak işaretlenmesidir.

On branch validation-rule
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  both modified:   validator.py

Bu aşamada henüz commit oluşturulmaz. Önce dosyanın içeriğini ve iki tarafın ne yapmaya çalıştığını incelemek gerekir.

5. Marker satırlarını ve iki davranışı yorumlama

Dosyanın mevcut hâlini açtığınızda Git, çakışan bölümü marker satırlarıyla gösterir. Örneğin içerik şu yapıya benzeyebilir:

def validate_username(username):
<<<<<<<< HEAD
    if not username:
        return "Kullanıcı adı gerekli"
    if len(username) < 3:
        return "Kullanıcı adı en az 3 karakter olmalı"
=======
    username = username.strip()
    if not username:
        return "Kullanıcı adı boş bırakılamaz"
>>>>>>> normalize-rule
    return "Geçerli"

HEAD bölümü üzerinde çalıştığınız branch’in, yani validation-rule branch’inin içeriğini temsil eder. Alt bölüm merge edilen branch’ten gelir. Bu örnekte iki taraf da aynı fonksiyonun başlangıcını değiştirmiştir:

• İlk taraf minimum üç karakter kuralını korumak istiyor.
• İkinci taraf kullanıcı adını strip() ile temizlemek istiyor.
• İki tarafın boş değer mesajı farklıdır.
• Her iki tarafın gerekli davranışı tek başına diğer tarafı seçerek korunamaz.

Bu nedenle git checkout --ours veya git checkout --theirs gibi otomatik seçimler bu senaryoda yeterli değildir. Böyle bir seçim bir tarafın değişikliğini tamamen atabilir. Doğru çözüm, davranışları karşılaştırıp birleşik bir fonksiyon yazmaktır.

6. Bilinçli birleşik çözümü yazma

Bu örnekte önce boşluklar temizlenir, sonra boş değer kontrol edilir, ardından minimum uzunluk kuralı uygulanır. Böylece iki branch’in işlevsel amacı tek bir sıraya yerleştirilir:

def validate_username(username):
    username = username.strip()
    if not username:
        return "Kullanıcı adı gerekli"
    if len(username) < 3:
        return "Kullanıcı adı en az 3 karakter olmalı"
    return "Geçerli"

Burada marker satırlarının tamamı silinmiştir. Boşluk temizleme işlemi kontrol sırasının başına alınmıştır; çünkü kullanıcı yalnızca boşluklardan oluşan bir değer girerse, sonraki kontrollerin bunu gerçek bir kullanıcı adı sanmaması gerekir.

7. Stage öncesi diff kontrolü

Dosyayı kaydettikten sonra doğrudan commit etmek yerine önce stage edilmemiş farkı inceleyin:

git diff
git status

Diff çıktısında eski conflict marker’larının bulunmaması ve fonksiyonun birleşik hâlinin görünmesi beklenir. Örnek olarak diff’in ilgili kısmı şu mantığı göstermelidir:

-<<<<<<< HEAD
-    if not username:
-        return "Kullanıcı adı gerekli"
-    if len(username) < 3:
-        return "Kullanıcı adı en az 3 karakter olmalı"
-=======
-    username = username.strip()
-    if not username:
-        return "Kullanıcı adı boş bırakılamaz"
->>>>>>> normalize-rule
+    username = username.strip()
+    if not username:
+        return "Kullanıcı adı gerekli"
+    if len(username) < 3:
+        return "Kullanıcı adı en az 3 karakter olmalı"

Bu çıktıdaki asıl denetim noktası, yalnızca eski satırların silinmesi değildir. Yeni kodda hem strip() davranışı hem de uzunluk kontrolü yer almalıdır. Ayrıca hata mesajını neden “Kullanıcı adı gerekli” biçiminde seçtiğinizi de proje içindeki mevcut mesaj standardıyla karşılaştırmanız gerekir.

8. Stage etme, cached diff ve commit

git add validator.py
git status
git diff --cached
git commit -m "Kullanıcı adı doğrulama conflict'ini çöz"

git add validator.py yalnızca bu dosyayı stage eder. Ardından git status ile dosyanın çözülmüş ve commit’e hazırlanmış olduğunu kontrol edin. git diff --cached çıktısı, commit’e gidecek birleşik fonksiyonu göstermelidir.

Cached diff içinde beklenmeyen başka bir dosya veya hâlâ marker satırı görürseniz commit komutunu çalıştırmayın. Önce yanlış stage edilmiş dosyayı ayırın veya çözüm dosyasını yeniden düzenleyin.

9. Çözümün beklenen davranışını çalıştırma

Commit sonrasında fonksiyonun yalnızca sözdizimsel olarak değil, davranış olarak da doğru olduğunu kontrol edin:

python - <<'PY'
from validator import validate_username

samples = ["  Ada  ", " Al ", "  ", "A"]
for sample in samples:
    print(repr(sample), "=>", validate_username(sample))
PY

Beklenen mantıksal sonuç şöyledir:

• " Ada " önce temizlenir ve geçerli kabul edilir.
• " Al " temizlendikten sonra iki karakter kaldığı için reddedilir.
• Yalnızca boşluklardan oluşan değer temizlendikten sonra boş kabul edilir.
• "A" minimum uzunluk kuralı nedeniyle reddedilir.

Bu senaryoda otomatik olarak yalnızca “ours” seçilseydi boşluk temizleme davranışı kaybolacaktı. Yalnızca “theirs” seçilseydi minimum uzunluk kontrolü kaybolacaktı. Conflict çözmenin amacı, marker’ları kaldırmak değil, bu iki davranışın birlikte doğru sırada çalışmasını sağlamaktır.

Çözüm Sonrası Güvenli Çalışma: Test, Geri Dönüş ve Commit

Conflict çözümü, dosyadaki marker’ları silmekle veya git commit çalıştırmakla bitmez. Güvenli bir sonuç için önce dosya kapsamı ve diff incelenmeli, sonra ilgili test veya çalıştırılabilir doğrulama senaryosu uygulanmalı, en son commit oluşturulmalıdır. Test edilmemiş bir conflict çözümü, hatalı davranışı commit geçmişine kalıcı olarak taşıyabilir.

Commit öncesi son doğrulama sırası

1. Marker satırlarını arayın ve çözülmemiş blok kalmadığını kontrol edin.
2. git status ile conflict durumunu ve dosya kapsamını inceleyin.
3. git diff ile stage edilmemiş değişiklikleri kontrol edin.
4. git add <dosya> ile yalnızca incelediğiniz dosyaları stage edin.
5. git diff --cached ile commit’e gidecek son içeriği inceleyin.
6. İlgili testleri veya en azından çalıştırılabilir doğrulama senaryosunu çalıştırın.
7. Test sonucu bekleniyorsa anlamlı bir commit mesajı yazın.
8. Commit sonrasında yeniden git status çalıştırın.

Marker araması için kullanılan komut proje yapısına ve kabuk ortamına göre değişebilir. Unix benzeri ortamlarda aşağıdaki komut, takip edilen dosyalarda yaygın conflict marker biçimlerini aramak için kullanılabilir:

git grep -n -E '^()' -- .

Çıktı alınmaması, bu desenlerle eşleşen marker bulunmadığını gösterir. Ancak bu kontrol yalnızca metinsel marker’ları arar; yanlış birleştirilmiş iş mantığını bulamaz. Bu nedenle marker araması testin yerine geçmez.

Test yapılmadan commit oluşturmanın riski

Bir conflict çözümü sözdizimsel olarak geçerli olabilir fakat uygulamanın beklenen davranışını bozabilir. Örneğin bir doğrulama fonksiyonunda hata mesajı korunmuş olsa bile, kontrol sırası değiştiği için geçersiz bir değer kabul edilebilir. Benzer şekilde bir API istemcisinde iki branch’in timeout ve hata işleme değişiklikleri birleşirken, fonksiyonun dönüş değeri farkında olmadan kaybolabilir.

Test komutu her projede aynı değildir. Python projesinde doğrudan bir betik, pytest veya proje içindeki başka bir test komutu kullanılabilir. Java tarafında JUnit tabanlı yapı, Maven veya Gradle görevleriyle çalıştırılabilir. Önemli olan tek bir aracı evrensel çözüm gibi görmek değil, projenin mevcut test ve çalıştırma düzenine uygun doğrulamayı yapmaktır.

Test başarısız olursa hemen yeni bir commit oluşturmayın. Önce hatanın conflict çözümünden mi, önceden var olan bir problemden mi kaynaklandığını ayırmaya çalışın:

• Hata doğrudan çözülen fonksiyon veya dosyayla ilgiliyse birleşik mantığı tekrar okuyun.
• Test çıktısında beklenmeyen değer varsa iki branch’in davranışını ayrı ayrı karşılaştırın.
• Sözdizimi hatası varsa marker temizliği sonrasında eksik parantez, girinti veya blok kapanışı arayın.
• İlgisiz bir test bozulduysa yanlış dosyanın stage edilip edilmediğini ve diff kapsamını kontrol edin.

Değişiklik kaybını önlemek için geri dönüş noktaları

Conflict çözmeye başlamadan önce mevcut durumu anlamlı bir geri dönüş noktasıyla korumak yararlı olabilir. Örneğin merge işleminden önce mevcut commit’i gösteren bir yedek branch oluşturabilirsiniz:

git branch before-conflict-resolution
git status

Bu branch, o andaki commit geçmişine işaret eder. Çalışma ağacındaki henüz commit edilmemiş değişiklikleri kendiliğinden ayrı bir commit olarak saklamaz; bu nedenle yedek branch’in neyi koruduğunu doğru anlamak gerekir.

Conflict sırasında çalışma ağacındaki farkı ayrıca bir patch dosyasına aktarmak da seçeneklerden biridir:

git diff > conflict-resolution.patch
git status

Patch yaklaşımı, düzenlemeyi kaybetme riskini azaltmak için ek bir kopya sağlayabilir. Ancak patch dosyasını körü körüne geri uygulamak yerine içeriğini incelemek gerekir. Özellikle aynı dosyada farklı aşamalarda hem staged hem de unstaged değişiklik varsa, hangi farkın patch’e dahil olduğunu kontrol etmeden geri yükleme yapmak yeni bir karışıklık oluşturabilir.

Commit geçmişini incelemek için kısa bir özet alabilirsiniz:

git log --oneline --decorate --graph -n 8

Bu çıktı branch’lerin nerede ayrıldığını ve merge commit’in geçmişte nasıl konumlandığını anlamaya yardımcı olur. Geçmişi incelemek, conflict çözümü sırasında hangi değişikliğin hangi commit’ten geldiğini takip etmeyi kolaylaştırır.

Sık karşılaşılan üç durum için teşhis yolu

Yanlış dosyayı stage ettim

Önce git status ve git diff --cached çıktısını kontrol edin. Yanlış dosyayı commit’e almak istemiyorsanız stage alanından çıkarın:

git restore --staged path/to/wrong-file
git status

Bu işlem yanlış dosyadaki çalışma değişikliğini silmez. Dosya hâlâ çalışma ağacında değişmiş görünüyorsa, onu ayrıca inceleyebilir veya proje politikanıza uygun biçimde saklayabilirsiniz.

Çözüm sırasında kendi değişikliğimi sildim

Önce stage alanında veya çalışma ağacında hâlâ bir kopya olup olmadığını kontrol edin. git diff, git diff --cached, yedek branch ve oluşturduğunuz patch dosyası farklı geri dönüş noktaları sağlayabilir. Dosyada artık yalnızca diğer branch’in yaklaşımı varsa, otomatik bir seçim yapmadan önce kendi branch’inizdeki ilgili commit’i inceleyin.

Buradaki amaç kaybolan satırı rastgele geri eklemek değil, silinen davranışın birleşik çözümde gerçekten gerekip gerekmediğini yeniden değerlendirmektir.

Test başarısız oldu

Başarısız testi, conflict çözümündeki belirli bir davranışla eşleştirin. Girdi, beklenen çıktı ve gerçek çıktı arasındaki farkı yazılı olarak karşılaştırın. Ardından dosyada yeniden düzenleme yapıp sırasıyla git diff, stage etme, git diff --cached ve test adımlarını tekrarlayın.

Çalışma ağacını temizleyen veya değişiklikleri geri alan komutları test başarısızlığının nedenini anlamadan çalıştırmayın. Hızlı bir temizlik, teşhis için gerekli kanıtı ortadan kaldırabilir.

Çözüm sonrası güvenli çalışma kontrol listesi

• Marker araması: <<<<<<<<, ======= ve >>>>>>> satırları kaldı mı?
• Dosya kapsamı: Yalnızca conflict çözümüyle ilgili dosyalar mı değişti?
• Diff incelemesi: git diff çıktısında silinen ve eklenen satırlar mantıklı mı?
• Stage alanı: git diff --cached commit’e gidecek doğru içeriği gösteriyor mu?
• Davranış: İki yaklaşımın gerekli işlevi birleşik çözümde korunuyor mu?
• Test: Projenin kendi test veya doğrulama senaryosu çalıştırıldı mı?
• Commit mesajı: Mesaj, yapılan çözümün amacını anlaşılır biçimde belirtiyor mu?
• Son durum: Commit sonrasında git status beklenmeyen değişiklik gösteriyor mu?

Git conflict çözme, yalnızca terminalde birkaç komut çalıştırma işi değildir; değişikliklerin kapsamını ve davranışını kanıta dayalı biçimde kontrol etme sürecidir. Bu süreçteki pratikleri ve farklı Git senaryolarını pekiştirmek için Git ve yazılım geliştirme blog içerikleri ek okuma olarak kullanılabilir.

Merge ve Rebase Ayrımı: Bu Sorunda Bilinmesi Gereken Sınır

Merge ve rebase, farklı branch’lerdeki çalışmaları birleştirmek için kullanılan iki ayrı Git işlemidir. Conflict çözme açısından temel fark, çakışmanın hangi işlem sırasında ortaya çıktığı ve commit’lerin hangi akış içinde ele alındığıdır. Her iki yöntemde de marker satırlarını okumak, doğru kod davranışını seçmek, değişiklikleri git diff ile incelemek ve test etmek gerekir.

Merge sırasında conflict nasıl ele alınır?

Merge, iki branch’in mevcut geçmişini birleştirmeye çalışır. Örneğin kendi branch’inizdeki çalışmayı başka bir branch ile birleştirirken Git, aynı dosyanın aynı bölümünde uyumsuz değişiklikler bulursa işlemi tamamlayamaz ve conflict durumuna geçer.

Bu durumda genel akış şöyledir:

1. git status ile conflict içeren dosyaları belirleyin.
2. Dosyadaki marker satırlarını okuyup hangi değişikliğin korunacağına karar verin.
3. Dosyayı düzenleyerek geçerli ve tutarlı son hâline getirin.
4. git diff ile çalışma alanındaki çözümü inceleyin.
5. Doğru dosyayı git add ile stage alanına alın.
6. git diff --cached ile commit’e girecek içeriği tekrar kontrol edin.
7. Testleri çalıştırdıktan sonra merge işlemini tamamlayın.

Merge sırasında conflict çözümü tamamlandığında genellikle mevcut merge işlemini tamamlayan bir commit oluşturulur. Buradaki önemli nokta, conflict’i yalnızca Git’in beklediği biçimde kapatmak değil, iki branch’in davranışlarını birlikte değerlendirmektir. Bir dosyada marker kalmaması, kodun doğru çalıştığı anlamına gelmez.

Rebase sırasında conflict nasıl ele alınır?

Rebase, mevcut branch’in commit’lerini başka bir tabanın üzerine yeniden uygulayan bir işlemdir. Bu nedenle conflict, iki branch’i tek seferde birleştirme aşamasında değil, commit’ler sırayla yeni tabana uygulanırken ortaya çıkabilir.

Örneğin branch’inizde üç ayrı commit bulunduğunu düşünün. Rebase sırasında ilk commit sorunsuz uygulanabilir, ikinci commit bir dosyada conflict oluşturabilir ve üçüncü commit’e henüz geçilmemiş olabilir. Bu durumda yalnızca o an uygulanmaya çalışılan commit’in oluşturduğu çakışmayı çözmeniz gerekir.

Genel rebase akışı şu mantıkla ilerler:

git status
# Conflict içeren dosyaları incele ve düzenle
git diff
git add yolu/degisen-dosya.py
git diff --cached
git rebase --continue

git rebase --continue komutu, mevcut commit’in çözülmüş hâliyle yeniden uygulanmasına devam edilmesini ister. Sonraki commit’te yeni bir conflict oluşursa aynı inceleme ve doğrulama döngüsü tekrar edilir. Yani rebase sırasında conflict çözümü tek seferlik olmayabilir.

Çözüm sırasında seçimin yanlış olduğunu fark ederseniz veya işlemi sürdürmek güvenli görünmüyorsa, devam etmek yerine rebase’i iptal etme seçeneği değerlendirilir:

git rebase --abort

Bu komut, rebase başlamadan önceki duruma dönme amacı taşır. Ancak komut çalıştırmadan önce çalışma alanında ayrıca korunması gereken bağımsız değişiklikler bulunup bulunmadığını kontrol etmek önemlidir. Git işlemlerinde geri dönüş seçeneklerini bilmek, aceleyle dosya silmekten veya yanlış çözümü kalıcı hâle getirmekten daha güvenlidir.

Merge ve rebase için ortak conflict çözme ilkesi

İşlemin adı merge veya rebase olsa da dosya içindeki conflict marker’ları aynı düşünceyle ele alınır. Marker’lar, Git’in iki farklı içerik arasında otomatik karar veremediğini gösterir. Çözüm sırasında amaç, yalnızca “üst tarafı” veya “alt tarafı” seçmek değil, programın gerektirdiği doğru birleşimi oluşturmaktır.

• Değişikliklerin hangi ihtiyacı karşılamak için yapıldığını anlayın.
• Bir tarafın kodunu doğrudan silmeden önce diğer tarafın davranışını inceleyin.
• Gerekirse iki değişikliği birleştiren yeni bir kod yazın.
• Fonksiyon imzası, değişken adı, dönüş değeri ve hata yönetimi gibi bağlantılı bölümleri kontrol edin.
• Dosyada marker kalmadığını ve gereksiz kod parçalarının silindiğini doğrulayın.
• Çözümden sonra test çalıştırmadan işlemi tamamlanmış kabul etmeyin.

Bu nedenle ours veya theirs seçenekleri, her conflict için otomatik doğru cevap değildir. Bir taraf eski ama çalışan davranışı koruyor olabilir; diğer taraf ise yeni gereksinimi getiriyor olabilir. Bazen doğru çözüm iki tarafı seçmek değil, iki tarafın amacını anlayarak üçüncü bir düzenleme yapmaktır.

Hangi durumda mevcut merge akışı, hangi durumda ekip prosedürü?

İşlem sırasında açıkça bir merge başlatıldıysa, conflict dosyalarını inceleyip düzenleme, stage etme, diff kontrolü ve test adımlarından oluşan mevcut merge çözüm akışını uygulayabilirsiniz. İşlem bir rebase sırasında başladıysa aynı inceleme döngüsünü her uygulanan commit için tekrarlamanız ve gerektiğinde devam etme ya da iptal etme kararını bilinçli vermeniz gerekir.

Ancak branch’in paylaşılmış bir geçmişi varsa, rebase sonrasında geçmişin nasıl güncelleneceği konusunda kendi varsayımınızla hareket etmeyin. Ekip deposunun branch ve geçmiş değiştirme politikasını kontrol edin. Özellikle başka kişilerin kullandığı branch’lerde geçmişi yeniden yazma, uzak depoya gönderme ve force push gibi adımlar proje prosedürüne bağlı olabilir.

Kısa karar çerçevesi şöyledir: Önce işlemi teşhis edin, sonra dosyayı çözün, ardından diff ve test ile davranışı doğrulayın. İşlem paylaşılan bir branch’i veya ortak geçmişi etkiliyorsa, teknik komuttan önce ekip prosedürünü kontrol edin.

Sık Sorulan Sorular

Git conflict oluştuğunda ilk olarak hangi komut çalıştırılmalı?

İlk olarak git status çalıştırılmalıdır. Bu komut, hangi işlemin devam ettiğini ve hangi dosyalarda conflict bulunduğunu görmenizi sağlar. Dosyaları görmeden rastgele düzenleme yapmak veya yanlış dosyayı stage etmek değişiklik kaybı riskini artırır.

Conflict marker satırları dosyadan nasıl temizlenir?

<<<<<<<, ======= ve >>>>>>> marker satırları, dosyanın hangi bölümlerinin çakıştığını gösterir. Önce iki tarafın kodunu okuyup doğru davranışı belirlemeli, ardından gereksiz bölümleri ve marker’ları silerek geçerli kodu bırakmalısınız. Sonrasında dosyayı kaydedip git diff ile sonucu kontrol edin.

Git conflict çözerken ours veya theirs seçmek neden her zaman doğru değildir?

Bu seçenekler bir tarafın içeriğini bütünüyle koruyabilir; ancak conflict’in gerçek çözümü bazen iki tarafın amacını birleştirmeyi gerektirir. Bir taraf fonksiyonun yeni parametresini, diğer taraf hata kontrolünü içeriyor olabilir. Taraflardan birini tamamen seçmek, çalışan bir davranışı veya gerekli bir değişikliği silebilir.

git diff ile git diff --cached arasındaki fark nedir?

git diff, henüz stage edilmemiş çalışma alanı değişikliklerini gösterir. git diff --cached ise git add sonrasında stage alanına alınmış ve bir sonraki commit’e girmeye aday içerikleri gösterir. Conflict çözümünde ilk komut düzenlemenin genel sonucunu, ikinci komut ise commit’e hazırlanmış kesin içeriği kontrol etmek için kullanılır.

Conflict çözüldükten sonra commit atmadan önce hangi kontroller yapılmalıdır?

Önce git status ile doğru dosyaların stage edildiğini kontrol edin. Ardından git diff --cached çıktısında marker, yanlışlıkla silinmiş kod veya ilgisiz değişiklik bulunmadığından emin olun. Son olarak projeye uygun testleri ve mümkünse ilgili komutun normal çalışma senaryosunu çalıştırın. Test sonucu doğrulanmadan commit oluşturmak, conflict’i teknik olarak kapatsa bile hatalı davranışı kalıcı hâle getirebilir.

Güvenli conflict çözümü, hızlıca bir tarafı seçmekten çok; inceleme, karşılaştırma, düzenleme, diff ile doğrulama ve test adımlarını sırasıyla uygulamaktır.