GIT BRANCHING STRATEJİLERİ

Aynı projede iki ekip aynı anda farklı kararlar veriyor: biri her gün main dalına merge ediyor, diğeri haftalarca süren feature branch'lerle çalışıyor. Hangisi doğru? Cevap ekibe, ürüne ve release temposuna göre değişiyor. Trunk-Based Development hızlı entegrasyon vaat ederken GitFlow sürümlü ürünlerde disiplin getiriyor, GitHub Flow ise sürekli teslimat yapan ekiplere sadelik sunuyor. Yanlış strateji; çatışmaları büyütür, dağıtımı yavaşlatır, ekibin moralini bozar. Doğru strateji ise neredeyse görünmez biçimde geliştirme akışını rahatlatır.

1. Dallanma Stratejisi Neden Önemli

Git, esnek bir araç olduğu için onlarca farklı dallanma modeli mümkündür. Ancak ekip içinde ortak bir kural setine bağlı kalmadan çalışmak; merge çatışmaları, kayıp commit'ler, bozuk release süreçleri olarak geri döner. Dallanma stratejisi aslında bir ekip anlaşmasıdır: kim ne zaman, nereye yazar; kod hangi aşamada doğrulanır; sürümler nasıl kesilir.

Strateji seçerken üç temel parametreye bakılır:

• Ekip büyüklüğü: 3 kişilik ekiple 50 kişilik ekibin çatışma riski aynı değildir
• Release temposu: Günlük deploy mu, üç ayda bir sürüm mü çıkarılıyor
• Ürün tipi: SaaS uygulaması mı, çoklu sürüm desteklenen kurumsal yazılım mı
• Test altyapısı: Otomatik test kapsaması düşükse uzun ömürlü branch'ler kaçınılmaz olabilir
• Müşteri çeşitliliği: Tek bir prod ortamı mı, yoksa farklı sürümler kullanan müşteriler mi var

2. Trunk-Based Development

Trunk-Based Development (TBD), tüm geliştiricilerin main (trunk) dalına günde en az bir kez kod entegre ettiği modeldir. Feature branch'ler ya hiç açılmaz ya da çok kısa ömürlüdür; tipik olarak 1-2 gün içinde kapanır. Yarım kalan özellikler feature flag arkasına gizlenir.

Bu yaklaşımın gücü, entegrasyon acısını sıfıra yakın tutmasıdır. Geliştiriciler birbirinin değişikliklerinden saatler içinde haberdar olur, büyük merge dramları yaşanmaz. Google, Facebook ve Netflix gibi şirketlerin tercih ettiği modelin temelinde bu vardır.

Ancak TBD'nin işlemesi için bazı önkoşullar gereklidir:

• Güçlü otomatik test paketi (unit, integration, end-to-end)
• Feature flag altyapısı
• Hızlı ve güvenilir CI pipeline
• Code review kültürünün hızlı işlemesi
• Kıdemli geliştirici oranı yüksek bir ekip

3. GitFlow Modeli

2010'da Vincent Driessen tarafından yayımlanan GitFlow, uzun yıllar boyunca standart dallanma modeli olarak görüldü. Modelde main (production), develop (entegrasyon), feature/*, release/* ve hotfix/* olmak üzere birden çok branch ailesi bulunur. Modelin tüm akış diyagramları ve örnek senaryoları için orijinal kaynak makaleyi inceleyebilirsiniz.

Akış şu şekilde işler:

1. Yeni özellik develop'tan bir feature branch açılarak geliştirilir
2. Tamamlanan feature, develop'a merge edilir
3. Sürüm hazırlandığında develop'tan release branch çıkarılır
4. Release branch'te yalnızca hata düzeltmeleri yapılır
5. Release tamamlanınca main'e ve develop'a merge edilir, tag atılır
6. Acil prod hatası için main'den hotfix branch açılır, çözüldükten sonra main ve develop'a döner

GitFlow'un asıl değeri, paralel sürümlerin desteklendiği ve release süreci formal olan ürünlerde ortaya çıkar. Örneğin müşterilerin v2.4 kullandığı, ekibin v3.0 geliştirdiği, prod'da v2.3 hotfix'i alınması gereken senaryolarda model olgun davranır. Buna karşılık SaaS ürünlerinde GitFlow çoğunlukla gereksiz karmaşıklık getirir; tek bir prod sürümü olan ekiplerde develop ve main arasındaki ikilik anlamsız bir overhead'e dönüşür. Git'in temel komutlarını yeniden hatırlamak isterseniz Git eğitimi içeriğinden yararlanabilirsiniz.

4. GitHub Flow ve GitLab Flow

GitHub Flow, GitFlow'un sadeleştirilmiş kuzenidir. Tek bir uzun ömürlü dal vardır: main. Her yeni iş için main'den kısa ömürlü bir branch açılır, geliştirme tamamlandığında pull request ile main'e merge edilir, ardından deploy edilir. Develop, release, hotfix gibi ek katmanlar yoktur.

Bu model özellikle sürekli teslimat (continuous deployment) yapan ekiplerde işe yarar. Her merge potansiyel bir prod deploy'udur; bu yüzden CI/CD pipeline'ının olgun olması beklenir.

GitLab Flow ise GitHub Flow'a "environment branch" kavramı ekler. main dışında staging, pre-production, production gibi ortam dalları tutulur ve kod bu dallar arasında sırayla ilerler. Çoklu ortamda ilerleyen ürünlerde GitHub Flow'un sadeliğini koruyup ortam yönetimi sağlar.

5. Ekip Büyüklüğü ve Strateji Eşleşmesi

Hangi modelin hangi ekibe uyduğunu netleştirmek için pratik bir eşleşme tablosu kuralım:

• 2-5 kişilik küçük ekip, SaaS: GitHub Flow ideal. Kısa branch, hızlı merge, sürekli deploy
• 5-15 kişilik orta ekip, güçlü test: Trunk-Based Development verim sağlar
• 15-50 kişilik ekip, modüler ürün: GitHub Flow + monorepo veya TBD + feature flag
• Çoklu sürüm destekleyen kurumsal ürün: GitFlow hâlâ en güvenli seçim
• Açık kaynak proje, çok sayıda dışarıdan katkıcı: Fork tabanlı + GitHub Flow benzeri
• Düşük test kapsaması olan legacy proje: GitFlow'un release branch disiplini risk azaltır

6. Release Temposu ile Uyum

Strateji seçiminde belki de en belirleyici parametre ne sıklıkta sürüm çıkarıldığıdır. Günde birden çok deploy yapan bir SaaS ekibine GitFlow zorla giydirilirse develop ve main arasındaki sürekli senkronizasyon ek bir maliyet yaratır. Tersine, üç ayda bir sürüm çıkaran bir ürün ekibine TBD önerildiğinde feature flag yönetimi başlı başına bir teknik borç haline gelir.

Genel pratik kural şudur: release sıklığı arttıkça branch sayısı azalmalı, release sıklığı azaldıkça branch'lerin görev tanımı netleşmelidir.

7. Geçişte Dikkat Edilecekler

Mevcut bir stratejiden başkasına geçiş, çoğu zaman teknik değil kültürel bir değişikliktir. GitFlow'dan TBD'ye geçen bir ekip; küçük PR alışkanlığı, feature flag kütüphanesi seçimi, code review SLA'sı gibi pek çok konuda yeniden anlaşma yapmak zorundadır.

Geçiş sürecini sağlıklı yürütmek için:

• Önce CI/CD pipeline'ını hedef stratejiye uygun hale getirin
• Yeni branch isimlendirme kurallarını yazılı hale getirin
• Bir pilot takım veya pilot servis üzerinde deneyin
• Eski uzun ömürlü branch'leri kapatın, kalıntı bırakmayın
• Code review sürelerini ölçmeye başlayın; uzun bekleyen PR strateji ne olursa olsun sorun yaratır

Hangi stratejiyi seçerseniz seçin, asıl mesele ekibin bu modeli istisnasız uygulayabilmesidir. En sade GitHub Flow bile yarım kalan PR'lar ve unutulan branch'lerle çürüyebilir; en katı GitFlow bile disiplinli bir ekibin elinde akıcı bir release motoru olabilir. Doğru cevap "GitFlow mu, Trunk-Based mi" değil; "ekibim hangisini sürdürebilir, ürünüm hangisini hak ediyor" sorusunun cevabıdır.