Git Branching Stratejileri: GitFlow ve Trunk-Based

Hızlı Özet (TL;DR)

Kurumsal yazılım mühendisliği ekipleri büyüdükçe ve aynı kod tabanı üzerinde eşzamanlı çalışan geliştirici sayısı arttıkça, kontrolsüz kod çakışmaları (Merge Conflicts), birbirini ezen sürümler ve haftalarca süren yayın hazırlıkları ciddi bir mühendislik darboğazına dönüşür. GitFlow; main, develop, release/*, feature/* ve hotfix/* gibi çok sayıda uzun ömürlü dala dayanan, yılda birkaç kez planlı ve numaralandırılmış paket sürüm (On-Premise / Gömülü Yazılım) çıkartan geleneksel projeler için tasarlanmıştır. Modern DevOps, mikroservis ve SaaS dünyasında altın standart haline gelen Trunk-Based Development (Gövde Tabanlı Geliştirme) ise geliştiricilerin günde birkaç kez doğrudan tek ana dala (main / trunk) çok kısa ömürlü dallarla birleştiği, Feature Flags (Özellik Bayrakları) ve tam otomatik CI/CD boru hatlarıyla desteklenen çevik yaklaşımdır.

1. Versiyon Kontrol Stratejisi Neden Mimari Bir Karardır?

Bir yazılım projesinde seçilen Git dallanma (Branching) stratejisi sadece geliştiricilerin hangi Git komutlarını (git merge, git rebase, git cherry-pick) çalıştıracağını belirlemez; şirketin müşteriye değer teslim etme hızını (Lead Time for Changes) ve üretim ortamında çıkan kritik bir hatayı çözme süresini (MTTR - Mean Time to Recovery) doğrudan tayin eder.

DORA (DevOps Research and Assessment) raporlarına göre, yüksek performanslı yazılım ekipleri; haftalarca ana daldan kopuk şekilde yaşatılan devasa özellik dallarından (Long-lived Feature Branches) kaçınmakta, bunun yerine küçük, atomik ve her an canlıya çıkabilir kod parçalarını günde birçok kez ana gövdeyle birleştirmektedir.

2. GitFlow Mimarisi: Ne Zaman Güçlü, Ne Zaman Yük?

2010 yılında Vincent Driessen tarafından tanımlanan GitFlow, yazılım dünyasında uzun yıllar boyunca en popüler dallanma modeli olmuştur. Bu modelde kod tabanının merkezinde iki adet ölümsüz ana dal bulunur:

• main (veya master): Yalnızca canlı üretim ortamında (Production) çalışan resmi ve etiketlenmiş (v1.2.0, v1.3.0) sürümleri barındırır.
• develop: Bir sonraki sürüm için geliştirilen tüm yeni özelliklerin toplandığı entegrasyon dalıdır.

GitFlow’un “Merge Hell (Birleştirme Cehennemi)” Sorunu

Bir geliştirici develop dalından feature/yeni-fatura-modulu adında bir dal açıp kendi bilgisayarında 3 hafta boyunca tek başına çalıştığında, bu 3 hafta içinde takımdaki diğer 8 geliştirici develop dalına yüzlerce yeni commit göndermiş ve veritabanı şemalarını değiştirmiş olur. 3. haftanın sonunda geliştirici kendi dalını develop ile birleştirmeye (Merge) çalıştığında yüzlerce dosyada binlerce satırlık Merge Conflict (Çakışma) ile karşılaşır. Kodu yazmak 3 hafta sürmüşken, çakışmaları çözmek ve bozulan yerleri onarmak 1 hafta daha kaybettirir.

Buna rağmen GitFlow; müşteri sunucularına kurulan (On-Premise) kurumsal yazılımlarda, endüstriyel PLC/gömülü sistem firmware projelerinde ve aynı anda hem v1.x hem de v2.x sürümlerine güvenlik yaması verilmesi gereken ürünlerde hâlâ geçerli ve düzenli bir yapı sunar.

3. Trunk-Based Development (Gövde Tabanlı Geliştirme) Mimarisi

Modern web uygulamaları, bulut tabanlı İmalat ERP ve CRM Çözümleri ve sürekli dağıtım (Continuous Deployment) yapılan projelerde GitFlow’un bürokrasisi yerine Trunk-Based Development kullanılır.

Bu modelin temel kuralları şunlardır:

1. Tek Gerçeklik Kaynağı (main): develop adında ikinci bir uzun ömürlü dal yoktur. Herkesin referans aldığı tek ana gövde main dalıdır ve main dalı her saniye canlıya çıkabilecek kadar sağlam (Always Green) tutulmak zorundadır.
2. Çok Kısa Ömürlü Özellik Dalları (Short-Lived Branches): Geliştirici main’den bir dal açar, en fazla birkaç saat veya maksimum 1–2 iş günü içinde küçük bir alt görevi tamamlar, otomatik testlerden geçirip tekrar main’e birleştirir ve dalı siler.
3. Sürekli Entegrasyon (True CI): Herkes günde en az bir kez main ile senkronize olduğu için kod tabanları birbirinden asla uzaklaşmaz ve büyük birleştirme çakışmaları matematiksel olarak ortadan kalkar.

4. GitFlow, GitHub Flow ve Trunk-Based Karşılaştırma Tablosu

Üç temel dallanma stratejisinin mühendislik kriterlerine göre detaylı karşılaştırması:

Karşılaştırma Kriteri	GitFlow Modeli	GitHub Flow Modeli	Trunk-Based Development
Uzun Ömürlü Ana Dallar	İki adet (main ve develop) + Sürüm dalları	Tek ana dal (main) + Orta ömürlü özellik dalları	Tek ana gövde (main / trunk)
Özellik Dalı Yaşam Süresi	Günler, haftalar veya aylar sürebilir	Genellikle 2 ila 5 gün arası	Birkaç saat veya en fazla 1 gün (<24 saat)
Sürüm ve Yayın Döngüsü	Planlı, seyrek sürümler (Ayda veya çeyrekte bir)	Özellik tamamlandıkça (Haftada birkaç kez)	Sürekli Dağıtım (Günde birçok kez canlı yayın)
Merge Conflict (Çakışma) Riski	Çok yüksek (“Merge Hell” sendromu)	Orta düzeyde	Çok düşük (Erken ve mikro birleştirmeler)
Zorunlu Altyapı Gereksinimi	Standart Git bilgisi ve manuel QA test süreci	Pull Request incelemesi ve temel CI testleri	Kapsamlı otomatik testler, CI/CD ve Feature Flags
İdeal Proje Profili	On-Premise paket yazılımlar, mobil market uygulamaları	Kurumsal web projeleri, açık kaynak kütüphaneler	SaaS platformları, mikroservisler, çevik B2B sistemler

5. Feature Flags (Özellik Bayrakları) ve Soyutlama ile Güvenli Dağıtım

Trunk-Based Development modeline geçmek isteyen ekiplerin aklına gelen ilk soru şudur: “Geliştirilmesi 3 hafta sürecek büyük bir muhasebe veya üretim planlama modülünü, henüz yarım haldeyken her gün main dalına nasıl birleştireceğiz? Canlıdaki kullanıcılar bozuk ekran görmez mi?”

Bu sorunun mühendislik cevabı Feature Flags (Özellik Bayrakları / Feature Toggles) ve Branch by Abstraction desenidir. Kod canlı üretim ortamına her gün dağıtılır (Deploy), ancak bir konfigürasyon anahtarıyla son kullanıcıların erişimine kapalı tutulur (Release ile Deployment birbirinden ayrılır):

// Özellik bayrağı ile canlı ortamda güvenli yönlendirme
export async function siparisMaliyetHesapla(siparisId: string, kullaniciRol: string) {
  const yeniMotorAktif = await featureFlags.isEnabled('yeni-dinamik-maliyet-motoru', {
    role: kullaniciRol,
  });

  if (yeniMotorAktif) {
    // Henüz geliştirilmekte olan yeni V2 hesaplama algoritması (Sadece iç test ekibine açık)
    return await yeniDinamikMaliyetMotoru(siparisId);
  }

  // Mevcut müşterilerin kesintisiz kullandığı kararlı V1 algoritması
  return await mevcutStandartMaliyetMotoru(siparisId);
}

Bu mimari sayesinde:

1. Yeni kod her gün main dalında derlenir ve birim/entegrasyon testlerinden geçer.
2. Özellik tamamlandığında önce yalnızca şirket içi kalite ekibine (role: 'QA'), ardından müşterilerin %5’ine (Canary Release) açılır.
3. Herhangi bir performans sorunu gözlenirse, sunucuyu geri almaya (Rollback) veya yeniden kod derlemeye gerek kalmadan bayrak milisaniyeler içinde false konumuna çekilerek eski kararlı akışa dönülür.

6. Kusursuz Bir Pull Request (PR) ve Code Review Kültürü İçin 5 Kural

Hangi dallanma stratejisi seçilirse seçilsin, kod kalitesini koruyan ana kapı Pull Request (Merge Request) ve Kod İnceleme (Code Review) disiplinidir:

1. Maksimum 200–300 Satır Kuralı: Bir PR’da 2.000 satır değişiklik varsa, inceleyen mühendis yorulur ve yalnızca “Görünüşe göre iyi (LGTM)” yazarak onaylar; ancak 150 satırlık odaklı bir PR’da tüm mantıksal hatalar ve güvenlik açıkları anında yakalanır.
2. Conventional Commits Standardı: Git geçmişinde "duzeltme", "son hal", "bug fix" gibi anlamsız mesajlar yasaklanmalıdır. Bunun yerine otomatik sürüm notu (Changelog) üretebilen feat(erp): recete agaci kopyalama eklendi, fix(auth): jwt yenileme yarisi giderildi formatı zorunlu tutulmalıdır.
3. Otomatik Kalite Kapısı (CI Pipeline): Bir PR açıldığı anda hiçbir insan müdahalesi olmadan Linter, TypeScript tip kontrolü, birim testleri (Unit Tests), derleme testi (npm run build) ve güvenlik/bağımlılık taraması (SAST) otomatik çalışmalı; bu kontrollerden biri bile kırmızıysa “Merge” butonu kilitli kalmalıdır.
4. Temiz Git Geçmişi (Squash and Merge / Rebase): Özellik dalında yapılan 15 adet deneme-yanılma commit’i ana dala birleştirilirken Squash and Merge ile tek bir anlamlı ve atomik commit haline getirilerek main geçmişinin doğrusal (Linear History) kalması sağlanmalıdır.
5. Güvenlik ve Sır Tarayıcıları (Secret Scanning): Kaynak kodun içine yanlışlıkla API anahtarı, veritabanı şifresi veya sertifika yazılmasını önlemek için Git pre-commit kancaları ve Sızma Testi ve Pentest standartlarına uygun statik kod analizi araçları aktif edilmelidir.

Çevik metodoloji, modern versiyon kontrol mimarisi, otomatik CI/CD boru hatları ve yüksek kod kalitesiyle hayata geçirilen kurumsal projeler için Özel Yazılım Geliştirme sayfamızı inceleyebilirsiniz.

Sıkça Sorulan Sorular

3-5 kişilik küçük bir yazılım ekibi için GitFlow mu yoksa Trunk-Based Development mı daha uygundur?

3 ila 8 kişilik çevik bir yazılım ekibi için GitFlow genellikle gereksiz bir bürokrasi ve zaman kaybı yaratır. Küçük ve orta ölçekli ekiplerde develop, release ve hotfix dalları arasında sürekli birleştirme yapmak yerine; tek bir main dalı üzerinden kısa ömürlü görev dallarıyla (feat/gorev-adi) çalışılan ve her PR’ın otomatik testlerden geçtikten sonra main’e birleştirildiği Trunk-Based Development veya yalın GitHub Flow modeli geliştirme hızını en az iki kat artırır.

git merge ile git rebase arasındaki fark nedir, ne zaman hangisi kullanılmalıdır?

git merge, iki dalın geçmişini birleştirirken yeni bir “birleştirme düğümü (Merge Commit)” oluşturur ve kronolojik çatallanmayı olduğu gibi korur; ancak çok sık yapıldığında Git grafiğini karmaşık bir spagettiye çevirir. git rebase ise kendi dalınızdaki değişiklikleri ana dalın (main) en son ucuna sanki yeni yazılmış gibi tek bir düz çizgi halinde taşır. Altın kural şudur: Kendi yerel özellik dalınızı güncellerken git pull --rebase kullanın, ancak ekipçe ortak kullanılan paylaşımlı (main) bir dalda asla geçmişi yeniden yazan (rebase + force push) işlem yapmayın.

Canlı ortamda (Production) acil bir hata çıktığında Hotfix süreci nasıl işletilir?

Trunk-Based modelde main dalı zaten her an canlıdaki kodla birebir aynı olduğu için, acil hata düzeltmesi doğrudan main’den açılan küçük bir fix/... dalında yapılır, otomatik CI testlerinden saniyeler içinde geçirilerek main’e birleştirilir ve doğrudan canlıya dağıtılır (Fix-Forward). GitFlow modelinde ise develop dalında henüz bitmemiş özellikler bulunduğu için, hotfix dalı mutlaka main üzerinden açılmalı ve düzeltme canlıya alındıktan sonra hem main hem de develop dalına ayrı ayrı birleştirilmelidir.