Küçük ekiplerde kurumsal GitFlow seremonisi çoğu zaman yavaşlatır. Bu rehber, canlıyı bozmadan özellik, düzeltme ve sürüm dallarını ayıran sade bir git branching stratejisini net adımlarla açıklar.
Küçük yazılım ekiplerinde en sık bozulan şey kod değil, dal disiplinsizliğidir. Bir özellik yarım kalır, hotfix doğrudan ana dala girer, sürüm notu dağılır. Net bir git branching stratejisi, canlı ortamı korurken ekibin aynı dili konuşmasını sağlar. Amaç kurumsal GitFlow’u kopyalamak değil; KOBİ ölçeğinde anlaşılır, sürdürülebilir ve az törenli bir iş akışı kurmaktır.
Bu rehberde özellik, düzeltme ve sürüm dallarının rollerini, ne zaman açılıp ne zaman kapanacağını ve hangi kuralların canlıyı gerçekten koruduğunu adım adım ele alıyoruz. KepezWeb olarak özel yazılım projelerinde de aynı sade modeli tercih ediyoruz: az dal, net sahiplik, kısa ömürlü özellik hatları.
Neden KOBİ’ye Sade Git Branching Stratejisi Gerekir
Kurumsal GitFlow; release, develop, feature, hotfix ve support gibi birçok uzun ömürlü dalı varsayar. İki-beş kişilik ekiplerde bu yapı genelde şu sorunları üretir:
- Geliştiriciler hangi dalın “doğru kaynak” olduğunu karıştırır.
- Merge ve rebase tartışmaları işi yavaşlatır.
- Acil düzeltme, yarım özelliklerle aynı hatta karışır.
- Staging ve canlı farkı belirsizleşir.
Sade modelde hedef basittir: canlıyı temsil eden tek güvenilir dal, kısa ömürlü özellik dalları ve yalnızca gerektiğinde açılan hotfix/sürüm hatları. Seremoni azaltılır; gözden geçirme ve test disiplini artırılır.
Temel Dallar ve Rolleri
Aşağıdaki iskelet çoğu KOBİ ekibi için yeterlidir. İsimler ekibin alışkanlığına göre değişebilir; roller değişmemelidir.
| Dal | Rol | Ömür |
|---|---|---|
| main (veya master) | Canlıya giden, her zaman deploy edilebilir kod | Kalıcı |
| develop (isteğe bağlı) | Bir sonraki sürümün entegrasyon hattı | Kalıcı veya dönemsel |
| feature/* | Yeni özellik veya görev | Kısa; iş bitince kapanır |
| hotfix/* | Canlıdaki kritik hata | Çok kısa; acil kapanır |
| release/* | Sürüm dondurma, son test ve etiketleme | Sürüm hazır olunca kapanır |
İki-üç kişilik ekiplerde develop olmadan da çalışılabilir: özellikler doğrudan main’e PR ile iner, staging’de doğrulanır, sonra canlıya alınır. Ekip büyüdükçe veya paralel sürümler çoğaldıkça entegrasyon dalı eklemek mantıklı hale gelir.
main dalı kuralı
main bozulmamalıdır. Doğrudan commit yasaklanmalı; yalnızca gözden geçirilmiş merge veya pull request kabul edilmelidir. Canlı deploy yalnızca bu daldan yapılmalıdır. Bu kural, yazılım geliştirme sürecinde kalite kapısını korumanın en ucuz yoludur.
Özellik Dalı İş Akışı
Özellik dalı, tek bir işi taşır. “Biraz da şunu ekleyeyim” yaklaşımı dalı şişirir ve review’u zorlaştırır.
- Güncel main (veya develop) üzerinden yeni dal açın: feature/siparis-filtreleri.
- Küçük, anlamlı commit’ler atın; mesajlar neyi neden değiştirdiğini söylesin.
- İş bittiğinde kendi dalınızı kaynak dala karşı güncelleyin (rebase veya merge; ekip tek yöntem seçsin).
- Pull request açın: amaç, test notu, riskli alanlar ve ekran/API etkisi yazılsın.
- En az bir kişi inceleyip onaylasın; ardından kaynak dala birleştirin.
- Özellik dalını silin. Açık ve unutulmuş dallar teknik borçtur.
Bir PR’da birden fazla bağımsız özellik taşımak, geri alma ihtiyacında maliyeti katlar. “Küçük PR, hızlı geri bildirim” ilkesi KOBİ hızını korur.
Ne zaman feature yeter, ne zaman ayrı iş gerekir
Aynı ekrandaki iki küçük metin düzeltmesi tek PR olabilir. Ödeme akışı ile raporlama paneli aynı dalda olmamalıdır. Bağımsız test edilemeyen işleri ayırmak, canlıya alma kararını da sadeleştirir.
Hotfix: Canlıyı Bozmadan Acil Düzeltme
Hotfix, “canlıda kullanıcıyı veya geliri doğrudan etkileyen hata” için açılır. Stil cilası veya yeni özellik hotfix değildir.
- main üzerinden hotfix/odeme-timeout açın.
- Sadece ilgili düzeltmeyi yapın; yan iyileştirme eklemeyin.
- Hızlı review + hedefli test: hata senaryosu ve yan etki kontrolü.
- main’e birleştirin, canlıya alın, sürüm etiketi atın.
- Eğer develop kullanıyorsanız aynı düzeltmeyi oraya da taşıyın; aksi halde hata sonraki sürümde geri döner.
Hotfix disiplini zayıf ekiplerde “acil” her şeye dönüşür ve ana dalın kalitesi düşer. Acil tanımını ekipçe yazmak, tartışmayı kısaltır.
Sürüm Dallanması ve Etiketleme
Sürüm dalı her deploy için şart değildir. Periyodik paket yayınlayan veya birden fazla özelliği aynı anda dondurması gereken ekiplerde işe yarar.
- release/1.4.0 açıldığında yeni özellik girişi kesilir.
- Yalnızca hata düzeltmesi, sürüm notu ve yapılandırma ince ayarı yapılır.
- Hazır olunca main’e merge edilir ve etiketlenir (v1.4.0).
- Entegrasyon dalı varsa oraya da geri birleştirilir.
Etiket, “canlıda ne vardı” sorusunun cevabıdır. Geri alma, destek ve müşteri bildirimi için etiket disiplini, uzun dal isimlerinden daha değerlidir. Özel ürünlerde sürüm izlenebilirliği, özel PHP/MySQL yazılım bakımını da kolaylaştırır.
İsimlendirme, PR ve Merge Disiplini
Strateji, dal isimlerinde bozulur. Ortak sözlük şarttır:
- feature/... yeni iş
- fix/... canlı dışı hata (henüz hotfix değilse)
- hotfix/... canlı acili
- chore/... bağımlılık, CI, temizlik
- docs/... yalnızca dokümantasyon
PR şablonunda minimum alanlar: amaç, test adımları, risk, geri alma planı. “LGTM” tek başına kalite kapısı değildir. Özellikle kimlik, oturum ve yetki değişen işlerde review derinleşmelidir; bu tür alanlar için ayrı bir kimlik doğrulama ve yetkilendirme kontrol listesi tutmak faydalıdır.
Merge stratejisi ekip kararıdır. Squash merge, geçmişi okunaklı tutar; merge commit geçmişi korur. Kararsızlık asıl sorundur: her PR’da farklı yöntem, git bisect ve geri almayı zorlaştırır.
Sık Yapılan Hatalar ve Pratik Düzeltmeler
- Doğrudan main’e commit: Dal koruması ve zorunlu PR açın.
- Haftalarca yaşayan feature: İşi parçalayın; entegrasyonu ertelemeyin.
- Hotfix’a yeni özellik eklemek: Acil kapsamı dondurun; özellik ayrı dalda kalsın.
- Develop ile main’in uzaklaşması: Sık birleştirme ve etiket geri taşıma rutini kurun.
- İsimsiz veya kişisel dallar: ali-deneme yerine iş odaklı isim kullanın.
- Review’suz “hızlı” merge: Hız kısa vadede artar, canlıda kaybolur.
Sade git branching stratejisi, araçtan çok ekip sözleşmesidir. Sözleşme yazılı, kısa ve görünür olmalıdır: hangi dal ne işe yarar, kim onaylar, ne zaman silinir.
Küçük Ekip İçin Örnek Günlük Akış
Üç kişilik bir ekip düşünün. Sabah main güncel. Geliştirici A sipariş filtresi için feature/siparis-filtre açar. Geliştirici B canlıda ödeme timeout görür, hotfix/odeme-timeout açar, düzeltir, review alır, canlıya alır ve etiketi günceller. A, B’nin hotfix’ini kendi feature dalına alır veya main ile senkronlar; böylece özellik dalı eski hatalı hali taşımaz. Öğleden sonra A’nın PR’ı incelenir, staging’de doğrulanır, main’e iner. Dallar silinir. Gün sonunda açık iş kadar açık dal kalır.
Bu ritim, KepezWeb’in KOBİ projelerinde aradığı dengeyi yansıtır: görünür ilerleme, düşük sürtünme, canlıya saygı.
Sıkça Sorulan Sorular
GitFlow kullanmadan da profesyonel olunur mu?
Evet. Profesyonellik dal sayısından değil; korunan main, gözden geçirme, test ve geri alınabilir deploy disiplininden gelir. KOBİ’de sade model çoğu zaman daha sağlıklıdır.
Develop dalı zorunlu mu?
Hayır. Paralel özellik azsa ve staging üzerinden doğrulama yapılıyorsa main + feature + hotfix yeterlidir. Entegrasyon karmaşası artınca develop eklenir.
Feature dalı ne kadar açık kalmalı?
Mümkünse günler, en fazla bir sprint parçası kadar. Haftalarca açık dal, merge çatışması ve “hatırlayamama” riski üretir. İşi bölmek utanç değil, kalite yöntemidir.
Hotfix’u develop’a taşımazsak ne olur?
Bir sonraki sürüm, düzelttiğiniz hatayı geri getirebilir. Hotfix main’e girdikten sonra entegrasyon hattına da yansıtılmalıdır.
Rebase mi merge mi tercih edilmeli?
Ekip tek politika seçsin. Ortak geçmişi sade tutmak istiyorsanız feature’da rebase + squash; tarihçeyi korumak istiyorsanız merge commit kullanılabilir. Karışık kullanım en pahalı seçenektir.
Dal stratejinizi netleştirmek, kod kalitesinin yanı sıra teslim hızını da etkiler. Ürün yol haritanız ve ekip büyüklüğünüze uygun sade bir model kurmak için teklif al sayfasından KepezWeb ile iletişime geçebilirsiniz. İhtiyaca göre iş akışını, review kapılarını ve dağıtım düzenini birlikte sadeleştiririz.
