Git Branching Stratejileri: Farklı Takımlar ve Ürünler için Gerçek Dünya Dersleri

Takım büyüklüğüne ve release temposuna uymayan bir Git dallanma stratejisi seçmek koordinasyon yükü, kırılan main branch’ler ve tıkanan deployment’lar doğurur. Takım büyüdükçe bu uyumsuzluk katlanır: üç geliştirici için ayarlanmış bir strateji yirmi beşte gereksiz sürtüşme yaratır, tersi de geçerlidir. Takımların çoğu için doğru varsayılan GitHub Flow’dur: kısa feature branch’ler, tek bir pull request kapısı, main’e merge. Kalan dört model ise yükünü yalnızca belirli bir kısıt altında hak eder: sürekli deploy, QA onay kapıları, environment programları ya da compliance audit trail’leri.

Sahada Kullanılan Beş Model#

Beş dallanma modeli neredeyse her takımı kapsar. Aralarındaki fark diyagramlarından çok test, review ve main’i kimin bozabileceği konusundaki varsayımlarda.

Trunk-Based Development#

Herkes direkt main’e (trunk) commit atar, feature branch’ler çok kısa yaşar (2 günden az).

Ne zaman uyar:

• Birbirine güvenen küçük takımlar (2-8 developer)
• Yeşil testle deploy etmeye güvenilecek kadar sağlam otomatik test paketi
• Tamamlanmamış işi gizleyen feature flag’ler
• Günde birden fazla deploy
• Kıdemli seviyede disiplin

Trunk-based tüm güvenlik ağını otomasyona taşır. Hızlı ve güvenilir bir test paketi ile feature flag’ler yoksa tek bir kötü commit herkesi aynı anda bloklar. Bilinen bir mühendislik organizasyonu duyurdu diye bu modele geçen ama test altyapısına ve on-call kültürüne aynı yatırımı yapmayan takımlarda main her gün bozulur, geliştiriciler de commit atmaktan çekinir.

Git Flow#

Main, develop, feature, release ve hotfix branch’lerinin her birinin tanımlı bir rolü var. Süreç ağır; programlı release yapan büyük takımlar için de güvenilir.

Uyduğu tablo dar: 50+ geliştirici, programlı release’ler, farklı amaçlara hizmet eden birden fazla environment, sıkı kalite kapıları (finans, sağlık) ve audit trail zorunlu kılan compliance kuralları. Continuous deployment yapan küçük bir takım bu koşulların hiçbirini karşılamaz.

Git Flow, öngörülebilir ve denetlenebilir release’leri geliştirici zamanını branch mekaniğine harcayarak satın alır: develop’ı senkronda tutmak, release branch’i kesmek, hotfix’i iki yere birden geri merge etmek. Programlı bir release treninde yaklaşık yüz geliştiricinin üzerinde bu maliyetten kaçmak zordur; bu çizginin altında ise aynı tören çok az şey kazandırır.

GitHub Flow#

Main artı feature branch’ler, pull request üzerinden çıkan release. Günlük ya da haftalık deploy eden, makul bir otomatik test kapsamı olan ve zaten birbirinin kodunu okuyan 5-30 kişilik takımlar burada eksik bir şey bulmaz.

GitHub Flow, trunk-based development’a tam olarak tek bir kapı ekler: pull request. Bu tek kapı code review’ı, CI’ı ve temiz bir rollback noktasını birlikte taşır; ağır modellerin vaat ettiğinin büyük kısmı zaten budur.

GitLab Flow#

GitHub Flow artı her deployment aşaması için environment branch’leri: GitHub Flow’dan fazla kontrol, Git Flow’dan az makine.

Environment’lar kendi programlarıyla ilerliyorsa, staging’de uzun test dönemleri varsa ya da dev, staging ve production’ın onay yolu birbirinden farklıysa (otomatik, manuel, komite) bu modele bakın. Düzenlenmiş sektörler genelde burada durur.

Tag-Based Release Flow#

Main’den feature branch’ler, PR’lar için preview environment’lar, otomatik dev deployment, staging’den production’a giden tag tetiklemeli release’ler. Production öncesinde QA onay kapısı gereken takımlara uyar.

Uçtan uca akış:

1. Feature Development

   git checkout main
   git pull origin main
   git checkout -b feature/payment-integration
   # Development çalışması
   git push origin feature/payment-integration

2. PR ve Preview

   • PR oluştur → Otomatik preview environment (preview-abc123.domain.com)
   • Preview’da code review ve testing
   • main’e merge → Dev environment’a otomatik deploy

3. Release Süreci

   # Tag oluştur ve push et
   git tag -a v1.3.0 -m "Release v1.3.0: Payment integration"
   git push origin v1.3.0
   
   # Bu şunları tetikler:
   # 1. v1.3.0 versiyonuyla build
   # 2. Staging'e deploy
   # 3. Otomatik testleri çalıştır
   # 4. QA takımını bilgilendir

4. QA ve Production

   • QA staging’de test eder (staging.domain.com)
   • CI/CD sisteminde manuel onay
   • Otomatik production deployment
   • Önceki tag ile rollback mevcut

Gerçek implementasyon (GitHub Actions):

# .github/workflows/release.yml
name: Release Pipeline

on:
  push:
    tags:
      - 'v*'

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    outputs:
      version: ${{ steps.version.outputs.VERSION }}
    steps:
      - uses: actions/checkout@v5
      - name: Versiyon çıkar
        id: version
        run: echo "VERSION=${GITHUB_REF#refs/tags/}" >> $GITHUB_OUTPUT

      - name: Staging'e Deploy
        run: |
          docker build -t app:${{ steps.version.outputs.VERSION }} .
          kubectl set image deployment/app app=app:${{ steps.version.outputs.VERSION }} -n staging

      - name: Integration Testleri Çalıştır
        run: npm run test:integration:staging

      - name: QA Takımını Bilgilendir
        uses: slackapi/slack-github-action@v1
        with:
          payload: |
            {
              "text": "Versiyon ${{ steps.version.outputs.VERSION }} staging'e deploy edildi",
              "staging_url": "https://staging.domain.com"
            }

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Production'a Deploy
        run: |
          kubectl set image deployment/app app=app:${{ needs.deploy-staging.outputs.version }} -n production

      - name: Deployment Doğrula
        run: kubectl rollout status deployment/app -n production

Her tag değişmez bir artifact’i isimlendirir; böylece QA hangi build’i test ettiğini bilir, main’deki geliştirme de release için durmak zorunda kalmaz. Tag listesi versiyon geçmişini tutar, dev’den staging’e ve production’a giden yolda ise tek bir manuel onay vardır.

Versiyon numaraları commit akışını takip edebilir:

// Semantic versioning otomasyonu
const bumpVersion = (currentVersion, changeType) => {
  const [major, minor, patch] = currentVersion.split('.').map(Number);

  switch(changeType) {
    case 'major': return `${major + 1}.0.0`; // Breaking change'ler
    case 'minor': return `${major}.${minor + 1}.0`; // Yeni feature'lar
    case 'patch': return `${major}.${minor}.${patch + 1}`; // Bug fix'ler
  }
};

// Commit mesajlarına göre
if (commitMessages.includes('BREAKING CHANGE')) {
  newVersion = bumpVersion(currentVersion, 'major');
} else if (commitMessages.includes('feat:')) {
  newVersion = bumpVersion(currentVersion, 'minor');
} else {
  newVersion = bumpVersion(currentVersion, 'patch');
}

Rollback da önceki tag’i seçmeye iner:

# Önceki versiyona acil rollback
git tag -l | grep '^v' | sort -V | tail -2 | head -1
# Önceki tag'i deploy et
kubectl set image deployment/app app=app:v1.2.9 -n production

# Ya da otomatik rollback
if [[ $(curl -s -o /dev/null -w "%{http_code}" https://api.domain.com/health) != "200" ]]; then
  echo "Health check başarısız, rollback yapılıyor..."
  kubectl rollout undo deployment/app -n production
fi

Ayrı bir QA fonksiyonu olan, kabaca on geliştiriciden büyük, haftalık veya iki haftalık release yapan ve compliance takibi tutan takımlar bundan en çok faydayı görür. Maliyet disipline biner. Tag atan herkesin semantic versioning’i bilmesi, staging konfigürasyonunun ve test verisinin production’ı öngörecek kadar yakın durması, acil patch’ler için de tanımlı bir sürecin olması gerekir.

Takım Büyüklüğü Kararı Nasıl Değiştirir#

Takım büyüklüğü bu kararın en güçlü tek girdisidir ve eşikler hiç de belirsiz değildir.

İki ile Beş Geliştirici#

Üç geliştiricide codebase’in tamamı hâlâ herkesin kafasına sığar. Buna uyan model:

Develop branch yok, release branch’ler yok, karmaşık flow yok. 3 kişiyle herkes codebase’in durumunu zaten biliyor, ek branch katmanları da yalnızca koordinasyon işi ekliyor.

Feature branch’ler main’den çıkar, main’e merge production’a deploy demektir, hotfix’ler doğrudan main’e gider ve main’i takip eden tek bir staging environment yeter. Bu ölçekte günde 5-10 deploy normal bir tempodur, çünkü model kimseyi beklemeye zorlamaz.

On ile Otuz Geliştirici#

Bu büyüklükte artık hiç kimse codebase’in tam durumunu kafasında tutamaz. Integration’ın kendine ait bir branch’e, release’lerin de bir stabilizasyon penceresine ihtiyacı olur.

Develop branch integration noktası olur, stabilizasyonu release branch’ler taşır, branch isimleri de ticket numarası taşımaya başlar; çünkü artık tracking opsiyonel olmaktan çıkar. Environment eşlemesi bunu takip eder:

# Environment mapping
environments:
  dev:
    branch: develop
    deploy: her_commit'te
    database: shared_dev

  staging:
    branch: release/*
    deploy: manual_trigger
    database: production_clone

  production:
    branch: main
    deploy: manual_onaylı
    database: production

Bu büyüklükte release’lerin tek bir sahibi olmalı. Sorumluluğu döndürmek tutarsız release’ler üretir, çünkü aynı kontrol listesine farklı kişiler farklı standartlar uygular.

Elli ve Üzeri Geliştirici#

Elli geliştiricinin üzerinde branch grafiği bir workflow olmaktan çıkar, organizasyon şemasını yansıtmaya başlar:

Pratikte faturası şu:

• Takıma özel develop branch’ler
• Günlük aktiviteye dönüşen cherry-picking
• Aynı anda ayakta duran birden fazla production versiyonu
• Zorunlu hale gelen feature flag’ler

Ürünün Dayattığı Kısıtlar#

Ürün tipi, hiçbir branching modelinin tartışamayacağı kısıtlar koyar: backend API’ler, mobil uygulamalar ve kütüphaneler farklı release mekaniğiyle çalışır.

Mobil Uygulamalar ve Review Kuyruğu#

Mobil development, backend odaklı branching stratejilerinin hesaba katmadığı kısıtlarla çalışır.

App store review 1-7 gün sürer, yani hızlı bir rollback yoktur. Kullanıcılar hemen güncellemez, dolayısıyla sahada aynı anda birkaç versiyon durur. Hotfix’lerin de review’dan geçmesi gerekebilir.

Buradan tanıdık bir sıra çıkar. Production’a kritik bir bug düşer, backend bir saat içinde fix’i deploy eder, mobil ise build’i gönderip bekler. Pratik cevap, yeni build geçene kadar bug’ı etkisizleştiren bir server-side workaround’dur; bu da release planlamasının o boşluğu baştan varsaymasını gerektirir.

Destek politikasını açık tutan bir versiyon tablosu işi kolaylaştırır:

// Versiyon yönetimi yaklaşımı
const releases = {
  "3.0.0": "deprecated, zorunlu güncelleme",
  "3.1.0": "destekleniyor, opsiyonel güncelleme",
  "3.2.0": "güncel production",
  "3.3.0": "beta test'te",
  "3.4.0": "development'ta"
};

Mikroservis Repoları#

Mikroserviste branching stratejisi, servis dependency’lerini hesaba katmak zorundadır. Her servis kendi branch’lerini tutar; ayrı bir integration repo’su ise test edilen versiyon kombinasyonlarını sabitler:

Başarısızlık öngörülebilir. v2.0’daki Service A, v1.5’teki Service B’ye bağlıdır; B kendi v2.0’ını çıkarır ve A production’da bozulur, çünkü ikisi yalnızca izole test edilmiştir. Bunu deployment’tan önce yakalayan şey, versiyon kombinasyonlarını lokalde sabitlemektir:

# Local testing için docker-compose.override.yml
services:
  payment:
    image: payment:${PAYMENT_VERSION:-develop}
  auth:
    image: auth:${AUTH_VERSION:-develop}
  inventory:
    image: inventory:${INVENTORY_VERSION:-develop}

# Developer'lar spesifik versiyon kombinasyonlarını test edebilir
# PAYMENT_VERSION=feature-new-flow AUTH_VERSION=main docker-compose up

Birden Fazla Major Sürümü Yaşayan Kütüphaneler#

Kütüphane geliştirme farklı kısıtlar altında çalışır. Aynı anda birden fazla major versiyonu desteklemek temel zorluktur:

# Library branching stratejisi
main (v4.x development)
├── v3.x (LTS, sadece security fix'ler)
├── v2.x (sadece kritik fix'ler)
├── next (v5.0 experimental)
├── feature/new-component
└── fix/v3.x-security-patch

Destek politikası, kimse backport istemeden önce yazılı olmalı:

{
  "releases": {
    "2.x": "2024-12'ye kadar sadece security fix",
    "3.x": "2025-06'ya kadar LTS",
    "4.x": "Güncel stable",
    "5.0-alpha": "Breaking change'ler, experimental"
  }
}

Versiyonlar arası feature parity kovalamak yaygın bir hatadır. Takım kapasitesinin büyük bölümü kimsenin talep etmediği feature’ları backport etmeye gider. Daha dar politika daha uzun ömürlü: yalnızca security fix ve kritik bug’lar.

Kaç Environment Gerekir#

Environment sayısı, branch sayısıyla aynı biçimde takım büyüklüğünü izler. Beş kişinin altında iki tane yeter:

Her PR kendi preview environment’ını alır, production main’i takip eder ve tüm taksonomi bundan ibarettir.

On ile otuz geliştirici arasında tanıdık dev/staging/production ayrımı yerini bulur. Önemli olan sayı değil, her environment’ın ne kadar disiplinle kullanıldığıdır:

environments:
  development:
    amaç: "Integration testing, en yeni kod"
    data: "Sentetik test verisi"
    erişim: "Tüm developer'lar"
    reset: "Her gün sabah 3'te"

  staging:
    amaç: "Pre-production validation"
    data: "Production snapshot (anonimleştirilmiş)"
    erişim: "QA + Product + seçili dev'ler"
    reset: "Asla (production gibi davran)"

  production:
    amaç: "Müşteri yüzü"
    data: "Gerçek veri"
    erişim: "Sadece SRE takımı"

İşler genelde staging’de bozulur, çünkü orası oyun alanı gibi kullanılır. Staging’i “production eksi bir gün” olarak ele almak, onu production’ı öngörecek kadar yakın tutar.

Enterprise tarafında liste uzar; 12 farklı environment tipine ulaşmak yaygındır:

environments:
  # Development environment'ları
  dev1: "Backend takım integration"
  dev2: "Frontend takım integration"
  dev3: "Mobile takım integration"

  # Test environment'ları
  qa1: "Otomatik test"
  qa2: "Manuel test"
  uat: "Business user acceptance"

  # Performance environment'ları
  perf: "Performance testing (production-scale)"
  chaos: "Chaos engineering"

  # Pre-production
  staging: "Final validation"
  canary: "5% production traffic"

  # Production
  production-eu: "Avrupa müşteriler"
  production-us: "ABD müşteriler"

Bu listenin büyük kısmı az kullanılır. Arkasındaki kalıp şu: her yeni gereksinim kendi environment’ını alır, production dışı bulut faturası takımdan hızlı büyür, environment’lar release’ler arasında boş durur ve konfigürasyonlarını senkron tutmak birinin tam zamanlı işine dönüşür. Eklenen her environment tekrarlayan bir fatura ve kalıcı bir senkron yükümlülüğü getirir; kaç tanesini ayakta tutmanın mantıklı olduğunu da pratikte bu belirler.

Testler Branch Modelinin Neresinde#

Branching’de en yaygın hata, testlerin nerede koşacağına karar vermeden branch modelini tasarlamaktır. Unit test’ler taban seviyedir:

# Bu build'ini fail etmeli, nokta
git push origin feature/my-feature
# Pre-push hook çalışıyor: npm test
# Test'ler fail ederse, push reddediliyor

Unit test’ler 2 dakikadan uzun sürüyorsa, bunlar unit test değildir. 45 dakika süren bir paket kılık değiştirmiş integration test’tir ve pipeline’ın daha ileri bir aşamasına aittir.

Integration Testlerinin Yeri#

Integration test’lerin nerede çalıştırılacağı konusunda yaygın başarısız yaklaşımlar:

1. Her feature branch’te - çok pahalı, çok yavaş
2. Sadece develop’ta - çok geç, herkesi bloklar
3. Sadece release branch’lerde - aşırı geç

Paketi PR durumuna göre bölmek daha iyi çalışır:

# .github/workflows/integration.yml
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  quick-integration:
    if: github.event.pull_request.draft == false
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - run: npm run test:integration:critical

  full-integration:
    if: contains(github.event.pull_request.labels.*.name, 'ready-for-review')
    runs-on: ubuntu-latest
    timeout-minutes: 45
    steps:
      - run: npm run test:integration:full

Her PR’da kritik test’ler, review için tag’lendiğinde full suite.

Büyük Ölçekte QA Kapıları#

Küçük takımlarda geliştiriciler kendi feature’larını production’dan önce staging’de test eder; on-otuz bandının bir yerinde bu devri ayrı bir QA kişisi ya da ekibi alır. Bunun üzerinde QA tek bir adım olmaktan çıkar:

Büyük organizasyonlarda tekrar eden bir başarısızlık var: QA bir feature’ı QA environment’ta onaylar, staging’de bozulur; çünkü QA environment’ta farklı feature flag’ler etkindir. Çözüm, QA’nın production benzeri konfigürasyonla staging’de test etmesidir.

Model Takımı Aştığında#

İki uyumsuzluk sık tekrar eder, her biri farklı yönde.

Startup Ölçeğinde Git Flow#

Dört kişilik bir takım, profesyonel görünen seçenek olduğu için tam Git Flow’a geçer. Deploy sıklığı günlükten haftalığa iner. İş artık uzun ömürlü branch’lerde beklediği için merge conflict’ler çoğalır. Takım da kendini yavaşlatan adımları atlamaya başlar, böylece yazılı süreçle fiilen işleyen süreç birbirinden uzaklaşır.

Büyüme Hızında Süreç Yok#

Takım birkaç çeyrekte dörde katlanır ama “main’e commit at” alışkanlığı korunur. Main mesai saatlerinde bozulur, incident’lar kapatıldığından hızlı birikir ve branching modeli bir planlama gününde değil outage baskısı altında yeniden yazılır. Eşik önceden planlanabilecek kadar tahmin edilebilir; model, takım o eşiğe varmadan sıradan bir çalışma gününde ayarlanabilir.

Seçimi Yapmak#

Alanı önce takım büyüklüğü daraltır:

İki-beş geliştirici: main production’a otomatik deploy eder, feature branch’ler preview environment alır ve iki environment tavandır. On-otuz: staging hattı olarak develop eklenir, release branch ise ancak stabilizasyon penceresi gerekiyorsa gelir. Elli ve üzeri: takım seviyesinde develop branch’ler, release branch’ler, her LTS hattı için bir support branch; environment’lar amaca göre ayrılır ve production’ın önünde canary durur.

Ürün tipi bunun üzerine kendi kurallarını koyar. Mobil takımlar en az üç versiyonu ayakta tutar: güncel production, development ya da review’daki sonraki release ve bir hotfix branch. Mikroservislerde her servis bağımsız dallanır, release branch’ler büyük feature’lar için koordine edilir ve ortak integrated environment eklemeden önce contract testing’e yaslanılır.

Takım büyüklüğünün açık bıraktığını release sıklığı ve compliance baskısı kapatır:

Modellerin Maliyeti#

Beş model yan yana:

Strateji	En İyi	En Kötü	Overhead	Öğrenme Eğrisi
Trunk-Based	Küçük, güvenilir takımlar	Büyük, dağıtık takımlar	Çok Düşük	Orta
GitHub Flow	Çoğu takım	Karmaşık compliance	Düşük	Kolay
Tag-Based Release	QA-gated release’ler	Continuous deployment	Orta	Kolay
GitLab Flow	Environment karmaşıklığı	Basit uygulamalar	Orta	Orta
Git Flow	Enterprise, compliance	Startup’lar, hız	Yüksek	Zor

Varsayılan Ne Zaman Geçerli#

GitHub Flow bir takımı yaklaşık beş ile otuz geliştirici arasında değişiklik gerektirmeden taşır. Bu varsayılanı yalnızca belirli bir kısıt zorladığında değiştirin. Trunk-based development, test paketi ve on-call kültürü main’e sürekli commit’i taşıyabildiğinde kazandırır. Tag-Based Release Flow, QA’in production’a çıkmadan önce isimlendirilmiş bir versiyonu onaylaması gerektiğinde uyar. GitLab Flow, environment’lar ayrı programlarla çalıştığında uyar. Git Flow ise compliance bir audit trail zorunlu kıldığında ya da organizasyon yaklaşık yüz geliştiriciyi geçip takımlar kendi integration branch’lerine ihtiyaç duyduğunda törenini hak eder.

Karar hangi yöne düşerse düşsün, adını koyabildiğiniz sorundan başlayın (yavaş deploy, merge conflict, production’a kaçan bug), her seferinde tek bir şeyi değiştirin ve takım bir büyüklük eşiğini geçtiğinde seçimi yeniden ele alın.

Kaynaklar#

• Kaynak Kodu Dallarını Yönetme Örüntüleri - Martin Fowler (yeni sekmede açılır) - Entegrasyon sıklığını, özellik bayraklarını ve kısa ömürlü dallar lehine argümanları kapsayan kapsamlı branching pattern katalogu
• Trunk Tabanlı Geliştirme (yeni sekmede açılır) - Tek bir trunk dalına sık commit yapma pratiğini, kısa ömürlü özellik dalları ve sürüm stratejileri hakkında kılavuzla belgeleyen referans sitesi
• Git Workflow Karşılaştırması - Atlassian (yeni sekmede açılır) - Trade-off analiziyle merkezi, özellik dalı, Gitflow ve fork workflow’larının pratik karşılaştırması
• GitHub Flow - GitHub Docs (yeni sekmede açılır) - Sürekli teslimat için tasarlanmış GitHub’ın hafif dal ve pull request workflow’unun resmi açıklaması
• Git - Referans Dokümantasyonu (yeni sekmede açılır) - Dal yönetimi komutları ve kavramları için yetkili kaynak olan resmi Git komut referansı ve kullanıcı kılavuzu