Branch protection nedir, neden ve nasıl kullanılır?

Bir ödeme servisinde başarısız istekleri yeniden deneme mantığını değiştirdiğinizi düşünün. Kod yerelde çalışıyor. Ancak ödeme sağlayıcısı işlemi tamamladıktan sonra yanıtı zamanında vermezse, yeniden deneme müşteriden iki kez ücret alınmasına yol açabilir. main dalına yapılan her push üretim dağıtımını başlatıyorsa, yerelde gözden kaçan bu hata doğrudan müşteriye ulaşabilir.

Ekip bu riski bildiğinde, yeniden deneme senaryosunu otomatik teste ekleyebilir ve değişikliği bir ekip arkadaşının incelemesini isteyebilir. Branch protection, main güncellenmeden önce bu koşulların sağlanmasını GitHub üzerinden zorunlu kılar.

Branch protection, bir Git dalının hangi koşullarda güncellenebileceğini belirleyen kuralların genel adıdır. Örneğin main dalına doğrudan push yerine pull request (PR) isteyebilir, merge için en az bir kod incelemesi onayı ve belirli CI kontrolleri şart koşabilirsiniz. Force push ve dal silme işlemlerini de engelleyebilirsiniz. GitHub bu kuralları uzak depodaki hedef dala uygular. Geliştiriciler kendi çalışma dallarında commit oluşturmaya ve değişikliklerini push etmeye devam eder. GitHub Docs · Protected branches

Doğrudan push’u önlemek, değişikliği incelemeye açar. PR, kod farkını, kararları ve test sonuçlarını tek yerde toplar. Ödeme örneğinde incelemeyi yapan kişi, ilk istek aslında başarılı olduysa ikinci isteğin nasıl ele alınacağını sorabilir.

Zorunlu kontroller, bilinen hataları merge öncesinde yakalar. Ödeme testinde sağlayıcının ilk isteği tamamlayıp yanıt vermediği durumu canlandırabilirsiniz. İkinci istek yeni bir ödeme oluşturursa test başarısız olur ve PR bekler. CI sonucunun değeri, ekibin hangi senaryoları teste dönüştürdüğüne bağlıdır.

Dal geçmişi, ekip için ortak bir referans olarak kalır. Force push, dalı eski bir commit’e taşıyıp ekip arkadaşlarının dayandığı commit’leri dal geçmişinden çıkarabilir. Dalı silmeye karşı koruma da aynı referansın yanlışlıkla kaybolmasını önler. GitHub Docs · Branch rules

Birden fazla geliştiricinin çalıştığı bir depoda main için bir PR, en az bir onay ve güvenilir CI kontrolleri makul bir başlangıçtır. Kuralı oluşturmak için yönetici erişimi veya depo kurallarını düzenleme yetkisi gerekir. GitHub Docs · Ruleset oluşturma

1. Önce CI’ı bir deneme PR’ında çalıştırın. GitHub Actions veya kullandığınız CI servisi build ve test gibi kontrolleri PR’a raporlasın. PR’da görünen kontrol adlarını doğrulayın. GitHub Docs · Required status checks
2. Bir branch ruleset oluşturun. Depoda Settings → Rules → Rulesets → New ruleset → New branch ruleset yolunu izleyin. Kural setine Protect main gibi bir ad verin. Target branches altında varsayılan dalı hedefleyin veya açıkça main dalını seçin. GitHub Docs · Hedef dalları seçme
3. PR ve onay şartını ekleyin. Require a pull request before merging seçeneğini açın ve gerekli onay sayısını 1 olarak ayarlayın. PR şartı ile onay sayısı ayrı ayarlardır. GitHub Docs · Pull request kuralları
4. CI ve dal geçmişi kurallarını ekleyin. Require status checks to pass before merging altında ilk adımda doğruladığınız kontrol adlarını seçin. Block force pushes ve Restrict deletions seçeneklerinin açık olduğunu kontrol edin. GitHub Docs · Branch rules
5. Kuralı etkinleştirin. Durumu Active olarak ayarlayıp kaydedin. Başlangıçta bypass listesini boş bırakabilirsiniz. Ekip veya bir GitHub App için istisna gerekiyorsa kapsamını belirleyin. Örneğin For pull requests only seçeneği, istisnayı kullanırken PR açmayı zorunlu tutar. GitHub Docs · Ruleset oluşturma ve bypass

Depoda klasik branch protection kullanılıyorsa, ayarları Settings → Branches altında bulursunuz. Klasik kurallarda yönetici ve bypass yetkisine sahip roller varsayılan olarak bazı kısıtlamaların dışında kalır. Kuralların bu rollere de uygulanması için Do not allow bypassing the above settings seçeneğini açın. Aktif bir ruleset ile klasik kural aynı dalı hedeflediğinde ikisi de uygulanır. GitHub Docs · Klasik kuralları yönetme, GitHub Docs · Ruleset’e geçiş

Ayarı bir deneme deposunda veya geçici bir hedef dalda, bypass yetkisi olmayan bir hesapla sınayın. Geçici dal kullanıyorsanız kuralın o dalı da hedeflediğini doğrulayın.

Zorunlu bir kontrol sürekli Waiting for status to be reported gösteriyorsa, PR’daki kontrol adıyla kuraldaki adı karşılaştırın. Ardından iş akışının bu PR için tetiklendiğini doğrulayın. Örneğin bir paths filtresi nedeniyle iş akışının tamamı atlanırsa GitHub zorunlu kontrolün sonucunu beklemeye devam edebilir. Sadece dokümantasyon değiştiren bir PR, bu sorunu erkenden ortaya çıkarır. GitHub Docs · Beklemede kalan kontroller

Onaydan sonra değişen bir kod farkının yeniden incelenmesini istiyorsanız, eski onayları düşüren ayarı açabilirsiniz. Ödeme veya yetkilendirme gibi alanlarda belirli kişilerin onayı gerekiyorsa, CODEOWNERS ile sahipliği tanımlayıp kod sahibi onayını zorunlu kılabilirsiniz. Sık merge yapılan bir dalda ise merge queue, değişiklikleri hedef dalın güncel hâli ve sıradaki diğer PR’larla birlikte kontrol eder. GitHub Actions kullanıyorsanız bu kontrolleri merge_group olayında da çalıştırın. GitHub Docs · İnceleme ve merge queue kuralları, GitHub Docs · Merge queue kontrolleri

Bir kontrolü zorunlu kılmadan önce ekibe şu soruyu sorun. Bu kontrol başarısız olduğunda hangi hatanın main dalına girmesini önlüyoruz? Yanıt henüz net değilse, kontrolü bir süre PR’larda bilgi amaçlı çalıştırın. Hangi hataları yakaladığını ve ekibi ne sıklıkta gereksiz yere beklettiğini gördükten sonra zorunlu olup olmayacağına karar verin.