GitHub Branch Yapısı

Ana Branch'ler

Main (veya Master) Branch

• Projenin kararlı ve yayınlanabilir sürümünü içerir
• Doğrudan commit yapılmaz
• Her commit production-ready olmalıdır
• Tag'ler ile sürüm numaraları işaretlenir

Develop Branch

• Ana geliştirme branch'i
• Feature branch'leri buradan açılır
• Tamamlanan özellikler buraya merge edilir
• Bir sonraki sürüm için hazırlık branch'i

Geçici Branch'ler

Feature Branch'leri

• Format: feature/ozellik-adi
• Yeni özellikler için oluşturulur
• Develop branch'inden açılır
• Tamamlandığında develop'a merge edilir
• Örnek: feature/login-system

Bugfix Branch'leri

• Format: bugfix/hata-aciklamasi
• Hata düzeltmeleri için kullanılır
• Develop branch'inden açılır
• Örnek: bugfix/login-error

Hotfix Branch'leri

• Format: hotfix/acil-duzeltme
• Production'daki acil hatalar için
• Main branch'inden açılır
• Main ve develop'a merge edilir
• Örnek: hotfix/security-patch

Release Branch'leri

• Format: release/x.y.z
• Sürüm hazırlığı için kullanılır
• Develop'dan açılır
• Main ve develop'a merge edilir
• Örnek: release/1.2.0

Branch Yönetimi İlkeleri

İsimlendirme Kuralları

• Küçük harfler kullanılır
• Kelimeler tire (-) ile ayrılır
• Açıklayıcı ve anlaşılır isimler seçilir
• Prefix'ler kullanılır (feature/, bugfix/, etc.)

Merge Stratejisi

• Pull Request kullanılır
• Code review zorunludur
• CI/CD testleri geçmelidir
• Çakışmalar çözülmelidir

Dokümantasyon

• Her branch'in amacı açıklanır
• Değişiklikler CHANGELOG.md'de belirtilir
• Release notları hazırlanır

Güvenlik

• Main branch korunur
• Direct push engellenir
• Code review zorunlu tutulur
• Branch protection rules uygulanır

En İyi Uygulamalar

Branch Temizliği

• Merged branch'ler silinir
• Eski branch'ler temizlenir
• Düzenli branch bakımı yapılır

Commit Mesajları

• Açıklayıcı commit mesajları
• Conventional commits kullanımı
• İlgili issue numaralarının belirtilmesi

Versiyon Yönetimi

• Semantic versioning kullanımı
• Release tag'leri oluşturulması
• CHANGELOG güncel tutulması