Merge — nedir, birleştirme türleri ve çalışma mekanizması

Merge Nedir?

Merge (birleştirme), Git'te bir daldan (kaynak) başka bir dala (hedef) değişiklikleri birleştiren temel bir işlemdir. Birleştirme sonucunda, hedef dal, kaynak daldaki henüz kendisinde bulunmayan tüm commit'leri alır. Duruma bağlı olarak, Git merge'i üç farklı şekilde gerçekleştirebilir.

Merge'in ana değeri geçmişi korumaktır: merge commit, dal birleştirme olayını kaydeder, ne zaman ve hangi dalların birleştirildiği hakkında bilgiyi saklar. Bu, değişiklik denetimini, regresyon aramasını ve geliştirme kronolojisini anlamayı kolaylaştırır. Büyük projelerde, merge commit kod entegrasyonunun standart yoludur.

GitLab Flow'a göre, Git ile çalışan ekiplerin %73'ü merge commit kullanmaktadır. Alternatif yaklaşımlar (rebase, squash) doğrusal geçmişe odaklanan ekipler tarafından tercih edilir. Strateji seçimi, ekip büyüklüğüne, sürüm sıklığına ve projede kabul edilen kurallara bağlıdır.

Merge Ne Zaman Gerekir

Merge, bir geliştirici bir özellik üzerinde çalışmayı bitirdiğinde ve bunu develop veya main'e entegre etmek istediğinde gereklidir. Tipik bir senaryo: bir geliştirici develop'tan bir özellik dalı oluşturdu, birkaç gün üzerinde çalıştı ve bu süre içinde develop'ta diğer ekip üyelerinden yeni commit'ler geldi. Birleştirmeden önce, değişikliklerin birleştirilmesi gerekir — ve bunun için merge kullanılır.

Merge olmadan, Git'te tek bir kod tabanı üzerinde işbirlikçi çalışmak imkansızdır. İki geliştirici aynı anda bir kod tabanında değişiklik yaptığında, dalları ayrışır. Merge, bu değişiklikleri veri kaybı olmadan geri getirmenin tek yoludur.

Git'te Birleştirme Türleri

Git üç tür merge destekler, her biri kendi senaryosu için tasarlanmıştır. Birleştirme türünün seçimi, commit geçmişini, geri alma kolaylığını ve log okunabilirliğini etkiler.

Fast-forward merge

Fast-forward, hedef dalda kaynak dal oluşturulduğundan beri yeni commit olmadığında gerçekleşir. Bu durumda, Git basitçe hedef dal işaretçisini kaynak dalın son commit'ine doğru ileri taşır. Geçmiş, merge commit olmadan doğrusal kalır.

# Fast-forward merge: özellik oluşturulduğundan beri develop değişmedi
git checkout develop
git merge feature/new-login

# Sonuç: develop işaretçisi özelliğin sonuna taşındı
# Hiçbir merge commit oluşturulmadı

Fast-forward, bir geliştiricinin tek başına çalıştığı kısa ömürlü dallar için uygundur. Ancak bu yaklaşımın bir dezavantajı vardır: dalın var olduğu bilgisi kaybolur — tüm commit'ler doğrudan develop'ta yapılmış gibi görünür.

Three-way merge

Three-way merge, ayrışma noktasından sonra her iki dalda da yeni commit'ler olduğunda gerçekleştirilir. Git, iki ebeveynli ayrı bir merge commit oluşturur ve bu commit dal birleştirme olayını kaydeder. Bu yaklaşım, ekip geliştirmesinde özellik dalları için önerilir.

# --no-ff bayrağıyla zorunlu three-way merge
git checkout develop
git merge --no-ff feature/new-login

# Varsayılan mesajla bir merge commit oluşturuldu
# -m ile kendi mesajınızı ayarlayabilirsiniz
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

--no-ff bayrağı, fast-forward mümkün olsa bile bir merge commit oluşturulmasını garanti eder. Bu, bir projede dallanma bilgilerini korumak için en iyi uygulamadır.

Squash merge

Squash merge, kaynak dalın tüm commit'lerini tek bir commit'te sıkıştırır ve hedefe uygular. Özellik geçmişi kaybolur — tüm değişikliklerle birlikte tek bir commit dala gelir. Bu, özellik dalındaki ayrıntılı commit'ler genel geçmişe değer katmadığında kullanışlıdır.

# Squash merge: özelliğin tüm commit'leri tek bir commit'te sıkıştırıldı
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash, taslaklar, deneysel dallar ve temiz bir geçmişi korumanın önemli olduğu durumlar için uygundur. Dezavantajı, orijinal commit'lerle bağlantının kaybolması ve bireysel değişikliklerin geri alınmasını zorlaştırmasıdır.

Ours ve Theirs Stratejileri

Ours ve Theirs, Git'te iki özel merge stratejisidir. Ours, kaynak daldaki değişiklikleri tamamen yok sayar, yalnızca hedefte olanı korur. Theirs ise tam tersine, herhangi bir çakışmada kaynak dal sürümünü kabul eder. Bu stratejiler, hangi sürümün baskın çıkması gerektiği önceden bilindiğinde büyük miktarda kod birleştirirken kullanışlıdır.

Merge Nasıl Çalışır

Git'teki merge mekanizması, üç noktanın karşılaştırılmasına dayanır: ortak ata (merge base), kaynak dalın durumu ve hedef dalın durumu. Git, merge base'i — her iki dalda ortak olan son commit'i — bulur ve ayrışmadan sonra her dalda hangi değişikliklerin olduğunu hesaplar.

• Adım 1 — Git merge base'i belirler: her iki dalda da bulunan son commit
• Adım 2 — Git iki diff oluşturur: merge base'ten kaynağa ve merge base'ten hedefe
• Adım 3 — Git her iki değişiklik setini merge base'e uygulamaya çalışır
• Adım 4 — Değişiklikler çakışmıyorsa — merge otomatik olarak tamamlanır
• Adım 5 — Çakışma varsa — Git durur ve çözüm ister

Git, karşılaştırılan iki dosya sürümünü değil, aynı zamanda ortak atalarını da dikkate alan üç yönlü bir birleştirme algoritması kullanır. Bu sayede Git, bir daldaki değişiklikler diğerinin değiştirilmiş alanlarını etkilemediğinde — her iki dosya da değiştirilmiş olsa bile — durumları otomatik olarak çözebilir.

Merge çalışma örneği

Bir senaryo düşünelim: iki geliştirici aynı özellik dalında farklı dosyalar üzerinde çalışıyor. Birincisi LoginActivity.kt'yi değiştirdi, ikincisi ProfileFragment.kt'yi değiştirdi. Değişikliklerini birleştirdiklerinde, Git değişikliklerin farklı dosyaları etkilediğini görür ve insan müdahalesi olmadan otomatik olarak merge'i gerçekleştirir.

Her iki geliştirici de LoginActivity.kt'yi değiştirdiyse, ancak farklı metodlarda — Git bunu da otomatik olarak halleder, değişiklikleri satır satır birleştirir. Çakışma yalnızca her ikisi de aynı satırları değiştirdiğinde veya biri diğerinin değiştirdiği kodu sildiğinde ortaya çıkar.

Merge Çakışmalarını Çözme

Merge çakışması, Git'in değişiklikleri otomatik olarak birleştirememesi durumunda ortaya çıkar çünkü her iki dal da aynı satırları farklı şekilde değiştirmiştir. Bu durumda, Git dosyalardaki çakışma alanlarını işaretler ve geliştiriciden manuel çözüm bekler.

Çakışma alanları özel işaretleyicilerle işaretlenir: <<<<<<< HEAD hedef dalın kodunu gösterir, ======= ayırıcıdır, >>>>>>> source-branch kaynak dalın kodunu gösterir. Geliştirici hangi sürümü koruyacağını manuel olarak seçmeli veya bunları birleştirmelidir.

# 1. Merge'i çalıştırın ve çakışmayı görün
git merge feature/new-login
# Çıktı: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. Çakışmalı dosyaların listesini görüntüleyin
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. Çakışmayı çözün: dosyayı düzenleyin, işaretleyicileri kaldırın
# 4. Çözülmüş dosyayı ekleyin ve merge'i tamamlayın
git add src/ui/login/LoginActivity.kt
git merge --continue
# veya: git commit (--continue olmadan)

Çakışmaları çözmek için araçlar vardır: git mergetool görsel bir birleştirici açar (Meld, Beyond Compare, VS Code). Birçok geliştirici çakışmaları IDE'de çözmeyi tercih eder — IntelliJ IDEA ve Android Studio, bu süreci büyük ölçüde basitleştiren üç panelli karşılaştırmalı yerleşik bir araç sağlar.

Çakışma çözümü için ipuçları: çakışmanın her iki tarafının ne yaptığını her zaman anlayın, mantığını anlamadan başkasının kodunu silmeyin ve çakışma çok karmaşıksa — her iki dalın yazarlarını ortak çözüme dahil edin.

Merge vs Rebase: Ne Zaman Hangisini Seçmeli

Merge ve Rebase arasındaki seçim, Git'teki en yaygın mimari kararlardan biridir. Her iki yaklaşım da değişiklikleri birleştirir, ancak farklı şekilde yapar: merge dallanma geçmişini korur, rebase geçmişi yeniden yazarak doğrusal hale getirir.

• Merge — bağlamı korur: ne zaman ve hangi daldan birleştirme yapıldığı görülebilir. Genel dallar (develop, main) ve ekip çalışması için daha iyidir
• Rebase — ekstra merge commit'leri olmadan temiz doğrusal bir geçmiş oluşturur. İncelemeden önce kişisel özellik dalları için daha iyidir
• Kural: diğer geliştiricilerin kullandığı genel dalları asla rebase yapmayın

Birçok ekip karma bir yaklaşım kullanır: özellik dalını develop ile güncellemek için rebase (git rebase develop) ve ardından birleştirmeyi kaydetmek için --no-ff bayrağıyla merge. Bu, özellik içinde temiz bir geçmiş ve develop seviyesinde bilgilendirici birleştirme noktaları sağlar.