Git Flow: Profesyonel Branching Stratejisi

Yazar:komut.io ekibi
0 Yorum

Bir projeye yeni katıldığınızda, repository’ye ilk baktığınızda ne görüyorsunuz? Eğer “main’e direkt push, main’e direkt push, main’e direkt push…” şeklinde bir commit geçmişi varsa, o projede ciddi sıkıntılar yaşandığını tahmin etmek için kâhin olmak gerekmiyor. Git Flow tam bu noktada devreye giriyor: kaotik bir geliştirme sürecini, öngörülebilir ve yönetilebilir bir sisteme dönüştürüyor.

Git Flow, Vincent Driessen’ın 2010 yılında önerdiği bir branching modelidir. Ama bunu sadece “bir model” olarak tanımlamak haksızlık olur. Doğru uygulandığında, ekibin nasıl çalıştığını, release süreçlerinin nasıl işlediğini ve acil düzeltmelerin nasıl yönetildiğini tamamen şekillendiren bir felsefedir.

Git Flow’un Temel Yapısı

Git Flow iki kalıcı branch ve üç geçici branch türü üzerine kurulur.

Kalıcı branchlar:

  • main (veya master): Her zaman production-ready kodu barındırır. Buraya direkt push yapılmaz.
  • develop: Bir sonraki release için geliştirilen kodların entegre edildiği branch. Nightly build veya staging environment bu branchtan beslenir.

Geçici branchlar:

  • feature/*: Yeni özellikler için
  • release/*: Release hazırlığı için
  • hotfix/*: Production’daki kritik hatalar için

Bu yapının güzelliği, herkesin nereye ne yapacağını bilmesinde yatıyor. Yeni geliştirici geldi, feature branch açtı, develop’a PR açtı, bitti. Kimse “bu kodu nereye pushlayayım?” diye sormak zorunda kalmıyor.

Git Flow Kurulumu

Önce git-flow extension’ını kuralım. Bu araç olmadan da Git Flow uygulayabilirsiniz ama bu araç işleri ciddi ölçüde kolaylaştırır.

# Ubuntu/Debian
sudo apt-get install git-flow

# macOS
brew install git-flow-avh

# Windows (Git Bash ile)
# Git for Windows genellikle dahili olarak gelir
# Yoksa: https://github.com/nvie/gitflow/wiki/Windows

Mevcut bir repository’yi Git Flow için başlatmak:

cd proje-dizini
git flow init

# Varsayılan değerleri kabul etmek için -d kullanabilirsiniz
git flow init -d

git flow init çalıştırdığınızda size şu soruları soracak:

Which branch should be used for bringing forth production releases?
   - main
Branch name for production releases: [main]

Which branch should be used for integration of the "next release"?
   - develop
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

Çoğu takım için varsayılan değerler idealdir. Prefix’leri değiştirmek genellikle gereksiz karmaşa yaratır.

Feature Branch Workflow

Bir feature geliştirmeye başladığınızda:

# Yeni bir feature branch başlat
git flow feature start kullanici-profil-sayfasi

# Bu komut şunları yapar:
# 1. develop'tan yeni bir branch oluşturur
# 2. feature/kullanici-profil-sayfasi branch'ine geçer

Geliştirme boyunca normal şekilde commit yapıyorsunuz:

git add .
git commit -m "feat: kullanici profil sayfasi temel yapisi eklendi"
git commit -m "feat: avatar yukleme ozelligi eklendi"
git commit -m "fix: email validation duzeltildi"

Feature tamamlandığında develop’a merge etmek:

git flow feature finish kullanici-profil-sayfasi

# Bu komut:
# 1. feature/kullanici-profil-sayfasi'ni develop'a merge eder
# 2. Feature branch'i siler
# 3. develop branch'ine geçer

Şimdi gerçek dünyada bu nasıl işliyor? Diyelim ki 5 kişilik bir ekipsiniz ve herkes farklı bir feature üzerinde çalışıyor:

# Ahmet kullanici-profil-sayfasi üzerinde çalışıyor
# Mehmet ödeme sistemi üzerinde çalışıyor
# Ayşe bildirim modülü üzerinde çalışıyor

# Her birinin kendi izole branch'i var
git branch -a
# feature/kullanici-profil-sayfasi
# feature/odeme-sistemi
# feature/bildirim-modulu
# develop
# main

Bu izolasyon kritik önem taşıyor. Ayşe’nin yarım bıraktığı bir feature, Mehmet’in production’a gitmesi gereken ödeme kodunu etkilemiyor.

Remote’a Feature Push Etmek

Takım ortamında çalışıyorsanız, feature branch’inizi remote’a pushlayarak başkalarının üzerinde çalışmasına izin verebilirsiniz:

# Feature branch'i remote'a yayınla
git flow feature publish kullanici-profil-sayfasi

# Başka bir geliştirici bu branch'i takip etmek isterse
git flow feature track kullanici-profil-sayfasi

# Remote'daki değişiklikleri çekmek için
git flow feature pull origin kullanici-profil-sayfasi

Code review süreciniz varsa (ki olmalı), feature’ı finish etmeden önce GitHub/GitLab’da pull request açıp review aldıktan sonra merge etmek daha sağlıklı. git flow feature finish komutu direkt merge yapıyor, araya insan gözü koymuyor.

Release Branch’leri

Ekip olarak “bu hafta sonu release çıkıyoruz” kararı verildi diyelim. Release branch açma vakti geldi:

# Release branch oluştur
git flow release start 1.2.0

# Bu komut:
# 1. develop'tan yeni bir release branch oluşturur
# 2. release/1.2.0 branch'ine geçer

Release branch’inde ne yapılır? Yeni özellik eklenmez. Sadece:

  • Bug fix’ler
  • Versiyon numarası güncellemesi
  • Changelog güncellemesi
  • Dokümantasyon güncellemeleri
# Versiyon dosyasını güncelle
echo "1.2.0" > VERSION
git add VERSION
git commit -m "chore: versiyon 1.2.0 olarak guncellendi"

# Changelog ekle
git add CHANGELOG.md
git commit -m "docs: 1.2.0 changelog eklendi"

# Son dakika bug fix'i
git add .
git commit -m "fix: login sayfasindaki timeout sorunu duzeltildi"

Release hazır olduğunda:

git flow release finish 1.2.0

# Bu komut:
# 1. release/1.2.0'ı main'e merge eder
# 2. main'i 1.2.0 olarak taglar
# 3. release/1.2.0'ı develop'a merge eder (bug fix'lerin develop'a da gitmesi için)
# 4. Release branch'ini siler

Release finish işlemi sırasında tag mesajı girmeniz istenecek. Buna boş geçmeyin, anlamlı bir release notu yazın.

Hotfix Workflow: Gece Yarısı Kabusu

Saat gece 2. Monitoring sistemi alarm veriyor, production’da kritik bir bug var. Kullanıcılar sisteme giremiyorr. Hotfix vakti.

# Ana daldan (main) hotfix branch'i aç
git flow hotfix start kritik-login-hatasi

# Bu komut main'den branch oluşturur, develop'tan değil
# Çünkü production'daki kodu düzeltiyoruz

Hatayı düzelt:

# Hatayı bul, düzelt, test et
git add .
git commit -m "fix: JWT token validation hatasi duzeltildi"

# Eğer birden fazla commit gerekiyorsa sorun yok
git commit -m "fix: edge case - expired token refresh sorunu"

Hotfix’i bitir:

git flow hotfix finish kritik-login-hatasi

# Bu komut:
# 1. hotfix branch'ini hem main'e hem develop'a merge eder
# 2. main'i taglar (örn: 1.2.1)
# 3. Hotfix branch'ini siler

Bu hotfix workflow’unun neden bu kadar önemli olduğunu anlatayım. Bir keresinde hotfix işlemini manuel yaparken, main’e merge etmeyi unutup sadece develop’a merge etmiştim. Sonuç? Production’daki bug iki hafta sonra yeni release’le “kendiliğinden” düzeldi ve kimse neden düzeldiğini anlamadı. Git Flow bu tür insan hatalarını sistematik olarak önlüyor.

Gerçek Dünya Senaryosu: E-ticaret Projesi

Bir e-ticaret projesi üzerinde çalıştığınızı düşünün. Sprint planlamasında şu tasklar var:

  • Sepet modülü yenileme (2 haftalık iş)
  • Kargo entegrasyonu (1 haftalık iş)
  • UI iyileştirmeleri (3 günlük iş)

Bunları nasıl yönetirsiniz?

# Sprint başlangıcında
git checkout develop
git pull origin develop

# Her task için ayrı feature branch
git flow feature start sepet-modulu-yenileme
# Geliştir, commit yap...
git flow feature publish sepet-modulu-yenileme
# PR aç, review al, merge et

git flow feature start kargo-entegrasyonu
# Geliştir, commit yap...
git flow feature publish kargo-entegrasyonu

git flow feature start ui-iyilestirmeleri
# Geliştir, commit yap...

Sprint sonunda release:

git flow release start 2.1.0
# Son testler, bug fix'ler
git flow release finish 2.1.0
git push origin main
git push origin develop
git push origin --tags

Tagları push etmeyi unutmayın! git flow release finish tagı lokalinizde oluşturuyor ama otomatik push etmiyor.

Merge Stratejileri ve Çakışma Yönetimi

Git Flow kullanırken merge stratejisi de önemli. Varsayılan olarak git flow recursive merge kullanır. Bazı takımlar squash merge tercih eder:

# Feature'ı squash merge ile develop'a eklemek
# (git flow finish bu seçeneği sunmaz, manuel yapmanız gerekir)
git checkout develop
git merge --squash feature/kullanici-profil-sayfasi
git commit -m "feat: kullanici profil sayfasi eklendi (#123)"
git branch -d feature/kullanici-profil-sayfasi

Squash merge’in avantajı temiz bir commit geçmişi. Dezavantajı ise feature branch’teki commit geçmişinin kaybolması. Takımınızın ihtiyacına göre karar verin.

Çakışma durumunda:

# Feature finish sırasında çakışma olursa
git flow feature finish kullanici-profil-sayfasi
# CONFLICT (content): Merge conflict in src/components/Header.jsx

# Çakışmayı çöz
git mergetool
# veya elle düzenle

git add src/components/Header.jsx
git commit -m "merge: feature/kullanici-profil-sayfasi develop'a merge edildi"

Git Flow ile CI/CD Entegrasyonu

Modern bir DevOps pipeline’ında Git Flow branchlarını farklı environment’lara bağlayabilirsiniz:

  • feature/* branchları: PR açıldığında otomatik test çalıştır
  • develop branchi: Staging environment’a otomatik deploy
  • release/* branchları: Pre-production environment’a deploy
  • main branchi: Production’a deploy

Örnek bir GitHub Actions workflow’u:

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches:
      - develop
      - 'release/**'
      - main

jobs:
  deploy-staging:
    if: github.ref == 'refs/heads/develop'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy to Staging
        run: |
          echo "Staging'e deploy ediliyor..."
          # deploy komutlarınız

  deploy-production:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy to Production
        run: |
          echo "Production'a deploy ediliyor..."
          # deploy komutlarınız

Bu yapı ile develop’a her merge geldiğinde staging otomatik güncellenirken, main’e merge geldiğinde production devreye giriyor.

Sık Yapılan Hatalar ve Çözümleri

Feature branch’ini güncel tutmamak: Uzun süren feature geliştirmelerinde develop ile aranız açılır. Düzenli olarak rebase veya merge yapın:

# Feature branch'inizdeyken develop'ı entegre edin
git checkout feature/uzun-soluklu-feature
git rebase develop
# veya
git merge develop

Release branch’ine yanlışlıkla yeni feature eklemek: Bu git-flow’un temel kuralını ihlal eder. Release branch’inde sadece bug fix yapılır. Eğer bir feature eksik kaldıysa, o feature’ı bir sonraki release’e erteleyin.

Hotfix sonrasında develop’a merge etmeyi unutmak: Git flow bunu otomatik yapıyor, ama manuel çalışıyorsanız:

# Hotfix main'e merge edildikten sonra
git checkout develop
git merge main
git push origin develop

Tag’ları push etmeyi unutmak:

# Tüm tagları push et
git push origin --tags

# Belirli bir tagı push et
git push origin v1.2.0

Git Flow’un Dezavantajları

Dürüst olmak gerekirse, Git Flow her projeye uygun değil. Bazı durumları değerlendirin:

Eğer continuous deployment yapıyorsanız, yani günde onlarca kez production’a deploy ediyorsanız, Git Flow fazla ağır gelebilir. GitHub Flow gibi daha basit bir model düşünün.

Eğer küçük bir takımsanız (2-3 kişi) ve hızlı hareket etmeniz gerekiyorsa, Git Flow’un overhead’i sizi yavaşlatabilir.

Eğer projenizin yalnızca bir production versiyonu varsa ve eski versiyonları desteklemeniz gerekmiyorsa, daha basit alternatifler işe yarayabilir.

Git Flow en iyi şu durumlarda parlıyor:

  • Scheduled release döngüleri olan projeler (haftalık, iki haftalık release)
  • Birden fazla production versiyonunu aynı anda destekleyen projeler
  • Büyük ekipler (5+ geliştirici)
  • Enterprise projeleri

Faydalı Git Flow Komutları Özeti

Günlük kullandığınız komutların hızlı referansı:

# Tüm feature branch'lerini listele
git flow feature list

# Tüm release branch'lerini listele
git flow release list

# Tüm hotfix branch'lerini listele
git flow hotfix list

# Mevcut git flow konfigürasyonunu görüntüle
git config --list | grep gitflow

# Feature branch'ini silmeden finish et (--keepremote)
git flow feature finish -k kullanici-profil-sayfasi

Sonuç

Git Flow ilk bakışta karmaşık görünebilir. “Neden bu kadar branch var?” sorusu kaçınılmaz geliyor. Ama birkaç sprint sonra ekibinizin ritmine oturduğunda, bu soruyu sormayı bırakıyorsunuz. Çünkü artık herkes nerede çalıştığını biliyor, release süreci öngörülebilir hale geliyor ve gece 2’deki hotfix senaryosu artık bir panik anı değil, sistemin olağan bir parçası haline geliyor.

Şunu da ekleyeyim: Git Flow’u “kitabına göre” uygulamak zorunda değilsiniz. Birçok takım kendi ihtiyaçlarına göre adapte ediyor. Önemli olan anlaşılmış, tutarlı ve ekibin gerçekten benimsediği bir branch stratejisine sahip olmak. Git Flow bu konuda sağlam bir başlangıç noktası sunuyor, geri kalanı size kalmış.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir