Git öğrenirken yaşanan en büyük sorun çoğu zaman komut eksikliği değildir. Geliştirici commit, branch, checkout, switch ve merge komutlarını bilir; fakat Git’in bu komutları çalıştırırken nasıl düşündüğünü tam olarak bilmez.

Bunun sonucunda birkaç soru sürekli tekrar eder:

• Yeni branch açınca dosyalar neden kopyalanmıyor?
• Commit, değişiklik listesi mi yoksa projenin tamamı mı?
• Merge sırasında Git hangi sürümü esas alıyor?
• Branch silinince commit’ler de siliniyor mu?
• HEAD tam olarak neyi gösteriyor?
• Aynı dosyayı değiştirmek neden her zaman conflict oluşturmuyor?
• Merge commit ile fast-forward arasındaki fark nedir?

Git’i ezberlemeden anlamak için commit, branch ve merge kavramlarını birbirinden bağımsız komutlar olarak değil, aynı commit grafiği üzerinde gerçekleşen işlemler olarak görmek gerekir.

Bu yazıda Git’in temel veri modelini inceleyecek, ardından gerçekçi bir ekip çalışması vakası üzerinden branch ve merge davranışlarını adım adım çözeceğiz.

Git’i Anlamanın Başlangıç Noktası: Dosyalar Değil Grafik

Git’i yalnızca “dosyaların eski sürümlerini saklayan bir araç” olarak düşünmek eksik bir zihinsel model oluşturur.

Git, özünde içerik adreslemeli bir nesne veritabanıdır. Dosya içeriklerini, dizin yapılarını ve commit bilgilerini nesneler hâlinde saklar. Commit’ler ise birbirlerine ebeveyn bağlantılarıyla bağlanarak yönlendirilmiş bir grafik oluşturur.

Basitleştirilmiş bir geçmiş şöyle görünebilir:

A ← B ← C

Burada:

• A ilk commit’tir.
• B, ebeveyn olarak A commit’ini gösterir.
• C, ebeveyn olarak B commit’ini gösterir.
• Geçmişi geriye doğru okumak için ebeveyn bağlantıları takip edilir.

Git’in çalışma mantığını anlamak için şu cümle kritik öneme sahiptir:

Commit’ler branch’lerin içinde bulunmaz. Branch’ler commit’leri işaret eder.

Bu ayrım, branch oluşturma, silme ve birleştirme davranışlarının büyük kısmını açıklamaya yeterlidir.

Commit Gerçekte Nedir?

Commit çoğu zaman “yaptığım değişiklikleri kaydetmek” şeklinde açıklanır. Kullanım açısından bu ifade doğrudur, fakat Git’in veri modelini tam olarak anlatmaz.

Bir commit temel olarak şu bilgileri taşır:

• Proje ağacının belirli bir andaki görünümüne referans
• Bir veya daha fazla ebeveyn commit
• Yazar ve kaydeden bilgileri
• Zaman bilgileri
• Commit mesajı

Git commit’i yalnızca “şu satırlar eklendi, şu satırlar silindi” biçiminde saklanan bir fark dosyası olarak ele almaz. Commit, projenin o andaki dosya ağacına referans veren bir anlık görüntüdür.

Git geçmişini incelerken gördüğümüz diff ise iki anlık görüntünün karşılaştırılmasıyla elde edilir.

Örneğin:

A ← B

B commit’inin getirdiği değişikliği görmek için Git, A ile B tarafından işaret edilen proje ağaçlarını karşılaştırabilir. Değişiklik, commit’in tek başına taşıdığı anlam değil; iki durum arasındaki ilişkidir.

Commit neden değiştirilemez kabul edilir?

Commit kimliği, commit içeriğinden üretilir. Commit mesajı, proje ağacı veya ebeveyn bilgisi değişirse farklı içerik ortaya çıkar ve yeni bir commit kimliği oluşur.

Bu nedenle geçmişi yeniden yazan işlemler var olan commit’i gerçekten düzenlemez. Eski commit’e benzeyen fakat farklı kimliğe sahip yeni bir commit üretir.

Örneğin:

A ← B ← C

B commit’inin içeriği değiştirildiğinde grafik şu hâle gelebilir:

A ← B' ← C'

B', yeni bir commit’tir. C de ebeveyn olarak eski B commit’ini gösterdiği için yeni zincirde C' olarak tekrar oluşturulmalıdır.

Bu bilgi; amend, rebase, cherry-pick ve force push işlemlerinin neden commit kimliklerini değiştirdiğini anlamanın temelidir.

Staging Area Neden Var?

Commit mantığını anlamak için working tree, staging area ve repository ayrımını bilmek gerekir.

Working tree

Dosyaların üzerinde çalıştığımız mevcut proje alanıdır. Editörde gördüğümüz değişiklikler burada bulunur.

Staging area

Bir sonraki commit’e girecek proje görünümünün hazırlandığı alandır. Git terminolojisinde index olarak da adlandırılır.

Repository

Commit ve diğer Git nesnelerinin saklandığı veritabanıdır.

Akış şu şekilde düşünülebilir:

Working tree → Staging area → Commit

git add komutu yalnızca “dosyayı Git’e tanıtmaz.” Dosyanın mevcut içeriğini bir sonraki commit için staging area’ya yerleştirir.

Bu yüzden aynı dosyanın yalnızca belirli değişikliklerini stage edip geri kalanını working tree’de bırakmak mümkündür. Staging area, geliştiriciye “hangi dosyaları kaydedeceğim?” sorusundan daha ayrıntılı bir kontrol sunar:

Bir sonraki commit’in proje görünümü tam olarak nasıl olmalı?

İyi commit tasarımı da burada başlar. Birbiriyle ilgisiz değişiklikleri aynı commit’e doldurmak yerine anlamlı ve geri alınabilir bir değişiklik birimi oluşturulabilir.

Branch Nedir?

Branch, bir commit’i gösteren hareketli referanstır.

Aşağıdaki geçmişte main, C commit’ini gösteriyor olsun:

A ← B ← C
        main

Yeni bir feature/payment branch’i oluşturduğumuzda Git bütün proje geçmişini kopyalamaz. Yalnızca aynı commit’i gösteren yeni bir referans oluşturur:

A ← B ← C
        main
        feature/payment

Dolayısıyla Git’te branch oluşturmak hızlı ve düşük maliyetlidir. Yeni branch, başlangıçta yeni commit veya yeni dosya kopyası üretmez.

feature/payment aktifken yeni bir commit oluşturursak yalnızca aktif branch referansı ilerler:

A ← B ← C ← D
        main   feature/payment

Burada:

• main, hâlâ C commit’ini gösterir.
• feature/payment, D commit’ini gösterir.
• D commit’inin ebeveyni C’dir.

Branch’ler commit saklayan klasörler değil, grafikteki belirli konumlara verilmiş hareketli isimlerdir.

HEAD Neyi Gösterir?

HEAD, çalışma alanında hangi konumun aktif olduğunu anlatan özel bir referanstır.

Normal kullanımda HEAD, doğrudan commit yerine aktif branch’i gösterir:

HEAD → feature/payment → D

Yeni commit oluşturulduğunda Git genel olarak şu süreci izler:

1. Staging area’daki proje ağacından yeni commit oluşturur.
2. HEAD üzerinden mevcut branch’i bulur.
3. Aktif branch’in gösterdiği commit’i yeni commit’in ebeveyni yapar.
4. Aktif branch referansını yeni commit’e taşır.

Bu nedenle commit atıldığında “branch’in ilerlemesi” aslında branch referansının yeni commit kimliğini göstermesidir.

Detached HEAD ne demektir?

Belirli bir branch yerine doğrudan bir commit checkout edilirse HEAD bir branch referansını değil, doğrudan commit’i gösterebilir:

HEAD → B

Bu durum detached HEAD olarak adlandırılır. Burada yeni commit oluşturmak mümkündür ancak commit herhangi bir branch adı tarafından otomatik olarak işaretlenmeyebilir.

Yeni commit’i korumak için o konumda bir branch oluşturulabilir. Aksi takdirde commit bir süre sonra erişilebilir referansların dışında kalabilir.

Uygulama Vakası: Ödeme Özelliği ve Acil Üretim Hatası

Bir yazılım ekibinin aşağıdaki geçmişle çalıştığını düşünelim:

A ← B ← C
        main

C, üretimde bulunan sürüm olsun. Ekip yeni ödeme akışı üzerinde çalışmak için bir branch açıyor:

git switch -c feature/payment

Git’in yaptığı işlem kavramsal olarak şudur:

A ← B ← C
        main
        feature/payment

Geliştirici iki commit oluşturuyor:

A ← B ← C ← D ← E
        main       feature/payment

• D: Ödeme formunun eklenmesi
• E: Form doğrulamasının eklenmesi

Bu sırada üretimde kritik bir vergi hesaplama hatası tespit ediliyor. Ödeme çalışması henüz tamamlanmadığı için bu değişikliklerin acil düzeltmeyle birlikte yayınlanması istenmiyor.

Geliştirici main branch’ine dönüyor ve hotfix/tax branch’ini oluşturuyor:

git switch main
git switch -c hotfix/tax

Bu noktada grafik şöyledir:

              D ← E  feature/payment
             /
A ← B ← C
             \
              hotfix/tax

Henüz hotfix commit’i oluşturulmadığı için hem main hem de hotfix/tax, C commit’ini gösterir. Düzeltme tamamlanıp commit edildiğinde yeni görünüm oluşur:

              D ← E  feature/payment
             /
A ← B ← C
             \
              F      hotfix/tax

Artık geçmiş iki kola ayrılmıştır. Git branch yapısının asıl değeri burada ortaya çıkar: Birbirinden bağımsız değişiklik dizileri aynı ortak geçmişten hareket ederek geliştirilebilir.

Fast-Forward Merge Nasıl Çalışır?

Hotfix’i main ile birleştirelim:

git switch main
git merge hotfix/tax

main, C commit’indedir. hotfix/tax ise C üzerinden doğrudan F commit’ine ilerlemiştir. main üzerinde farklı bir çalışma olmadığı için Git’in birleştireceği iki ayrı geçmiş yoktur.

Git yalnızca main referansını ileri taşır:

A ← B ← C ← F
            main
            hotfix/tax

Bu işlem fast-forward merge olarak adlandırılır.

Yeni bir merge commit oluşturulmamıştır. Çünkü main branch’inin gösterdiği C, F commit’inin geçmişinde zaten bulunmaktadır.

Fast-forward için sorulması gereken soru şudur:

Mevcut branch’in referansını hedef commit’e taşıdığımda herhangi bir geçmişi kaybetmeden doğru sonuca ulaşabiliyor muyum?

Cevap evetse Git referansı ileri taşıyabilir.

Gerçek Merge Ne Zaman Oluşur?

Hotfix yayınlandıktan sonra ödeme özelliği tamamlanır ve feature/payment branch’i main ile birleştirilmek istenir.

Mevcut grafik:

              D ← E  feature/payment
             /
A ← B ← C ← F        main

Bu defa main ve feature/payment, C commit’inden sonra farklı yönlerde ilerlemiştir.

E, F commit’inin devamı değildir. F de E commit’inin devamı değildir. Bu nedenle yalnızca bir branch referansını ileri taşımak yeterli olmaz.

Git üç temel noktayı kullanır:

1. Aktif branch’in ucu: F
2. Birleştirilecek branch’in ucu: E
3. İki kolun ortak atası: C

Bu işlem üç yönlü birleştirme, yani three-way merge olarak adlandırılır.

Birleştirme başarılı olduğunda Git yeni bir commit oluşturur:

              D ← E
             /     \
A ← B ← C ← F ←──── M
                   main

M normal bir commit’ten farklı olarak iki ebeveyne sahiptir:

• Birinci ebeveyn: F
• İkinci ebeveyn: E

Merge commit’in önemli özelliği yalnızca iki değişiklik kümesini içermesi değildir. Aynı zamanda iki geliştirme hattının hangi noktada bir araya geldiğini geçmişte açıkça kaydeder.

Merge Branch’leri Değil Commit’leri Karşılaştırır

“Git iki branch’i birleştirir” ifadesi günlük kullanım için yeterlidir fakat teknik açıdan daha doğru açıklama şöyledir:

Git, branch isimlerinin işaret ettiği commit’leri ve bu commit’lerin ortak atasını kullanarak yeni bir sonuç üretir.

Branch yalnızca doğru commit’i bulmaya yarayan isimdir. Merge tamamlandığında kaynak branch’in silinmesi merge sonucunu ortadan kaldırmaz.

Örneğin feature/payment silinse bile E commit’i merge commit üzerinden erişilebilir durumdadır:

              D ← E
             /     \
A ← B ← C ← F ←──── M
                   main

Branch silmek çoğu durumda commit silmek değil, bir referansı kaldırmaktır. Commit başka bir referans veya commit geçmişi üzerinden erişilebiliyorsa yaşamaya devam eder.

Merge Conflict Gerçekte Nedir?

Merge conflict, iki geliştiricinin aynı dosyayı değiştirmesi demek değildir.

Git çoğu zaman aynı dosyanın farklı bölgelerinde yapılan değişiklikleri otomatik olarak birleştirebilir. Conflict, Git’in ortak ataya göre yapılan değişikliklerden güvenli bir sonuç üretemediği durumda oluşur.

Vakadaki üç sürümü düşünelim:

Ortak ata C

KDV oranı: %18

main üzerindeki F

KDV oranı: %20

feature/payment üzerindeki E

Vergi oranı: yapılandırmadan okunur

Git yalnızca F ile E arasından birini seçmez. Her ikisini ortak ata C ile karşılaştırır:

• main, sabit oranı %18 değerinden %20 değerine değiştirmiştir.
• Feature branch, sabit oranı tamamen kaldırıp yapılandırma tabanlı hâle getirmiştir.

Aynı mantıksal bölge için iki farklı sonuç bulunduğundan Git geliştiricinin kararına ihtiyaç duyar.

Conflict çözmek, işaretleri silip dosyayı kaydetmek değildir. Doğru süreç şöyledir:

1. Ortak atadaki davranışı anlamak
2. Birinci branch’in niyetini belirlemek
3. İkinci branch’in niyetini belirlemek
4. Her iki gereksinimi karşılayan nihai davranışı tasarlamak
5. Testlerle sonucu doğrulamak
6. Çözülmüş dosyayı staging area’ya eklemek
7. Merge işlemini tamamlamak

Bu örnekte doğru sonuç, yapılandırma sistemini kullanırken yeni %20 oranının varsayılan veya güncel yapılandırma değeri olarak tanımlanması olabilir.

Conflict çözümü metin düzenleme değil, iki değişiklik niyetini uzlaştırma işidir.

“Ours” ve “Theirs” Neden Bağlama Göre Değişir?

Merge sırasında kullanılan “ours” ve “theirs” ifadeleri sabit branch adlarını temsil etmez.

Şu işlemde:

git switch main
git merge feature/payment

• Ours: Aktif branch, yani main
• Theirs: Birleştirilmek istenen feature/payment

Fakat branch yönü ters çevrilirse anlam da değişir:

git switch feature/payment
git merge main

Bu defa:

• Ours: feature/payment
• Theirs: main

Bu nedenle conflict çözerken “ours her zaman ana branch’tir” gibi bir varsayım ciddi veri kayıplarına yol açabilir. Önce aktif branch ve yürütülen operasyon kontrol edilmelidir.

Rebase sırasında kullanılan ours ve theirs kavramlarının algılanışı ise daha da şaşırtıcı olabilir; çünkü Git commit’leri yeni bir tabana yeniden uygulamaktadır. Bu yüzden etiket ezberlemek yerine operasyonun hangi grafiği üretmeye çalıştığını anlamak daha güvenlidir.

Merge ile Rebase Arasındaki Temel Fark

Merge ve rebase çoğu zaman “hangisi daha iyi?” sorusuyla karşılaştırılır. Asıl fark, geçmişi nasıl temsil ettikleridir.

Başlangıç grafiği:

              D ← E  feature
             /
A ← B ← C ← F        main

Merge uygulandığında iki geliştirme hattı korunur:

              D ← E
             /     \
A ← B ← C ← F ←──── M

Rebase uygulandığında D ve E değişiklikleri F üzerine yeniden uygulanır:

A ← B ← C ← F ← D' ← E'

Burada D' ve E', eski commit’lerle aynı değildir. Ebeveynleri ve dolayısıyla commit kimlikleri değişmiştir.

Merge:

• Mevcut commit’leri korur.
• Geliştirme kollarının birleşimini kaydeder.
• Gerekirse iki ebeveynli merge commit oluşturur.

Rebase:

• Commit’leri yeni taban üzerinde yeniden üretir.
• Daha doğrusal bir geçmiş sağlayabilir.
• Paylaşılmış commit’lerde dikkat gerektirir.

Karar, estetik bir log tercihinden fazlasıdır. Ekibin geçmişi nasıl okumak, incelemek ve geri almak istediğine göre verilmelidir.

Squash Merge Ne Yapar?

Squash merge, bir branch’teki değişikliklerin sonucunu hedef branch’e taşır ancak kaynak branch’in commit bağlantılarını merge commit şeklinde korumaz.

Örneğin feature branch’inde üç commit olsun:

A ← B ← C             main
         \
          D ← E ← F   feature

Squash merge sonrasında hedef geçmiş şöyle görünebilir:

A ← B ← C ← S         main

S, D, E ve F değişikliklerinin birleşik sonucunu içerir. Fakat S commit’inin ebeveyni yalnızca C’dir. Git grafiği açısından D, E ve F, main geçmişine merge edilmiş olarak bağlanmaz.

Squash merge:

• Deneme amaçlı veya düzensiz ara commit’leri ana geçmişten uzak tutabilir.
• Bir özelliği tek geri alınabilir commit olarak temsil edebilir.
• Ayrıntılı geliştirme geçmişini ana branch üzerinde kaybettirebilir.

Bu nedenle her pull request’i otomatik olarak squash etmek yerine değişikliklerin gelecekte nasıl inceleneceği değerlendirilmelidir.

Vaka Analizinin Sonucu

Ödeme özelliği ve üretim hotfix’i vakasında ekip şu kararları vermiş olsun:

1. Hotfix, main üzerine fast-forward ile alınır.
2. Ödeme özelliği güncel main ile test edilir.
3. İki geliştirme hattını görünür tutmak için feature branch merge commit ile birleştirilir.
4. Conflict çözümünde hem yeni vergi oranı hem de yapılandırma tabanlı sistem korunur.
5. Testler tamamlandıktan sonra feature branch referansı silinir.

Son grafik:

              D ← E
             /     \
A ← B ← C ← F ←──── M ← N
                   main

• F, acil vergi düzeltmesidir.
• M, ödeme özelliğini birleştiren merge commit’tir.
• N, birleştirme sonrasında yapılan ek doğrulama veya düzenleme commit’i olabilir.
• Feature branch silinse bile D ve E, M üzerinden erişilebilir durumdadır.

Bu vaka bize Git işlemlerinin komutlardan önce commit grafiği üzerinden okunması gerektiğini gösterir.

İleri Seviye Git Kullanımında Sorulması Gereken Sorular

Bir Git komutunu çalıştırmadan önce şu sorulara cevap vermek çoğu hatayı önler:

Şu anda HEAD nereyi gösteriyor?

Aktif branch’i ve çalışma konumunu bilmeden merge, reset veya rebase işlemi yapmak risklidir.

Hangi commit’ler birbirinin atası?

Fast-forward olasılığı ve branch’lerin ayrışma noktası bu ilişkiyle belirlenir.

Hangi referans hareket edecek?

Bir komutun dosyalar üzerindeki etkisi kadar branch, tag veya remote-tracking referanslarını nasıl değiştireceği de önemlidir.

Yeni commit mi oluşacak, mevcut referans mı taşınacak?

Fast-forward yalnızca referans taşıyabilir. Three-way merge ise yeni merge commit oluşturabilir. Rebase yeni commit kimlikleri üretir.

Geçmiş korunacak mı, yeniden mi yazılacak?

Merge çoğunlukla mevcut geçmişi korurken rebase ve amend yeni commit’ler oluşturur.

İşlem paylaşılmış commit’leri etkiliyor mu?

Henüz yalnızca yerel ortamda bulunan commit’leri yeniden düzenlemek ile ekip tarafından kullanılan bir branch’in geçmişini değiştirmek aynı risk seviyesinde değildir.

Git Geçmişini Okumak İçin Yararlı Komutlar

Komut ezberlemek yerine birkaç komutu commit grafiğini gözlemlemek için kullanmak daha öğreticidir.

Görsel commit grafiği

git log --graph --oneline --decorate --all

Bu çıktı:

• Commit bağlantılarını
• Branch ve tag referanslarını
• Merge noktalarını
• Aktif branch’in konumunu

tek görünümde incelemeye yardımcı olur.

Ortak atayı bulmak

git merge-base main feature/payment

Bu komut, iki geçmişin ortak atasını gösterir. Three-way merge davranışını analiz ederken özellikle yararlıdır.

Bir commit’in ebeveynlerini görmek

git show --no-patch --pretty=raw <commit>

Normal commit’lerde çoğunlukla tek, merge commit’lerde ise birden fazla parent satırı görülebilir.

Branch’lerin hangi commit’i gösterdiğini incelemek

git branch -vv

Yerel branch konumlarını ve varsa upstream ilişkilerini gösterir.

İki commit arasındaki farkı görmek

git diff <eski-commit> <yeni-commit>

Bu komut, commit’i “değişiklik paketi” gibi düşünmek yerine iki proje görünümünü karşılaştırma alışkanlığı kazandırır.

Yaygın Yanlış Zihinsel Modeller

“Branch, projenin ayrı bir kopyasıdır”

Branch dosya kopyası değil, commit referansıdır. Çalışma alanı branch değiştirildiğinde ilgili commit görünümüne göre güncellenir.

“Commit yalnızca değişen satırları saklar”

Git’in veri modeli commit’i proje ağacının belirli bir durumuna referans verecek şekilde oluşturur. Diff, durumların karşılaştırılmasıyla elde edilir.

“Merge son commit’leri yan yana koyar”

Three-way merge iki branch ucuyla birlikte ortak atayı da kullanır.

“Aynı dosya değiştiyse conflict çıkar”

Git, aynı dosyanın bağımsız bölgelerindeki değişiklikleri çoğu zaman otomatik birleştirir. Conflict, aynı mantıksal alan için uzlaştırılamayan değişikliklerde ortaya çıkar.

“Branch silinirse çalışmalar kaybolur”

Branch silmek bir referansı kaldırır. Commit’ler başka bir referans veya geçmiş üzerinden erişilebiliyorsa kaybolmaz. Ancak hiçbir referanstan erişilemeyen commit’lerin sonsuza kadar saklanacağı da varsayılmamalıdır.

“Rebase commit’leri taşır”

Rebase mevcut commit nesnelerini fiziksel olarak taşımaz. Değişiklikleri yeni ebeveynler üzerinde uygulayarak yeni commit’ler üretir.

Sonuç: Git Bir Komut Listesi Değil, Commit Grafiğidir

Git’i gerçekten anlamak için onlarca komutu ezberlemek gerekmez. Öncelikle birkaç temel gerçeği içselleştirmek yeterlidir:

• Commit, proje ağacının belirli bir anına referans veren değişmez bir nesnedir.
• Commit’ler ebeveyn bağlantılarıyla bir grafik oluşturur.
• Branch, grafikteki bir commit’i gösteren hareketli referanstır.
• HEAD, aktif çalışma konumunu belirler.
• Fast-forward merge yalnızca branch referansını ileri taşıyabilir.
• Three-way merge, iki branch ucu ile ortak atayı karşılaştırır.
• Merge conflict, Git’in değişikliklerin niyetine tek başına karar veremediği noktadır.
• Rebase, commit’leri taşımak yerine yeniden üretir.

Bir Git işlemi kafa karıştırdığında önce komut seçeneklerine değil, commit grafiğine bakın. “Hangi commit nereyi gösteriyor, ortak ata hangisi ve işlemden sonra hangi referans hareket edecek?” sorularını yanıtlayabiliyorsanız Git’in sonucunu büyük ölçüde önceden tahmin edebilirsiniz.

Komutlar zamanla değişebilir, yeni araçlar ortaya çıkabilir ve ekip iş akışları farklılaşabilir. Commit grafiğinin mantığı ise bütün bu arayüzlerin altında çalışmaya devam eder.

Sıkça Sorulan Sorular

Git commit değişiklikleri mi, projenin tamamını mı saklar?

Commit, projenin belirli bir andaki ağaç yapısına referans verir. Kullanıcı arayüzlerinde gördüğümüz değişiklikler, iki commit görünümünün karşılaştırılmasıyla oluşturulur. Git depolama katmanında aynı içerikleri verimli biçimde yönetmek için nesne ve paketleme mekanizmaları kullanır.

Git branch oluşturmak dosyaları kopyalar mı?

Hayır. Branch oluşturmak başlangıçta mevcut commit’i gösteren yeni bir referans oluşturur. Yeni commit’ler eklendikçe aktif branch referansı ilerler.

Merge commit neden iki ebeveynlidir?

Merge commit, daha önce farklı yönlerde ilerleyen iki geliştirme hattını birleştirdiği için iki branch ucunu ebeveyn olarak gösterir. Böylece geçmişteki birleşme ilişkisi korunur.

Fast-forward merge sırasında yeni commit oluşur mu?

Normal fast-forward işleminde yeni merge commit oluşturulmaz. Hedef branch referansı, geçmişte kendisinden ileride bulunan commit’e taşınır. Ekip politikası gerektiriyorsa --no-ff seçeneğiyle merge commit oluşturulması tercih edilebilir.

Aynı dosyanın değiştirilmesi her zaman conflict oluşturur mu?

Hayır. Değişiklikler dosyanın farklı bölgelerindeyse Git bunları otomatik olarak birleştirebilir. Conflict, ortak ataya göre yapılan değişikliklerden güvenilir tek bir sonuç üretilemediğinde oluşur.

Merge mi, rebase mi kullanılmalı?

Tek bir evrensel cevap yoktur. Merge geliştirme kollarının birleşme yapısını korur. Rebase daha doğrusal bir geçmiş oluşturabilir fakat commit kimliklerini değiştirir. Seçim, ekip politikası ve geçmişin nasıl okunmak istendiğine göre yapılmalıdır.

Branch silindiğinde commit’ler silinir mi?

Commit’ler başka branch, tag veya commit geçmişi üzerinden erişilebiliyorsa silinmez. Hiçbir referans tarafından erişilemeyen commit’ler ise hemen yok olmasa da ilerleyen dönemde Git’in temizleme işlemlerine konu olabilir.