GitHub Repository Rulesets: Kullanıcı Bypass ve Branch

Açık konuşayım: GitHub’ın repository ruleset tarafı uzun süredir bizim ekipte ara ara söylenip durduğumuz bir konuydu. Logosoft’ta yönettiğim bir bankacılık projesinde, sırf tek bir kişiye bypass yetkisi vermek için ad-hoc bir takım açtığımızı hatırlıyorum. Adı da biraz komikti, “ruleset-bypass-ahmet-temp” gıbı bir şeydi sanırım. Üç ay sonra kimse o takımın neden açıldığını hatırlamıyordu. İşte tam bu tıp yamuk işleri azaltan bir güncelleme geldi.

GitHub, 7 Mayıs’ta repository rulesets tarafına iki küçük ama sahada baya iş gören özellik ekledi. Birinçisi, bireysel kullanıcıları doğrudan bypass actor olarak ekleyebilmek. İkincisi de organization veya enterprise seviyesinde ruleset kapsamına giren branch’leri repo admin’i olarak yeniden adlandırabilmek. Küçük görünüyor, evet. Peki neden önemli? Çünkü gerçek hayatta sorun tam da burada çıkıyor; kağıt üstünde basit duran şeyler, production’da bazen gereksiz dolambaç oluyor.

Şimdi gelelim işin can alıcı noktasına.

İlk maddeyi biraz açayım. Eskiden bypass yetkisi vermek için çoğu ekip takım oluşturuyor, sonra o takımı yönetiyor, sonra da “bu takım burada niye duruyor?” diye birbirine bakıyordu; şimdi direkt kullanıcı bazlı tanımlama yapabildiğiniz için o fazladan katman kalkıyor (ve açıkçası bu, audit tarafını da daha temiz tutuyor). Hmm, ilk bakışta minicik bir detay gıbı duruyor ama operasyonel yükü baya azaltıyor.

İkinci madde de boşuna eklenmiş değil. Organization ya da enterprise seviyesinde kurallara takılan branch’leri repo admin’i olarak yeniden adlandırabilmek, özellikle standart dışı isimlendirme yüzünden kilitlenen akışlarda nefes aldırıyor; mesela eski bir release branch’i kalmış oluyor, üstüne policy geliyor ve siz basit bir rename işi için bile dolaş dolaş yetki arıyorsunuz (kendi tecrübem). Neyse uzatmayalım, bu tarz şeyler insana ufak görünür ama günün sonunda en çok zaman çalan yerler bunlar.

Evet.

Benim gözümde olayın özü şu: GitHub burada yeni bir sihir yapmıyor, sadece yıllardır etrafında dolandığımız iki gereksiz iş parçasını kesip atıyor. Siz ne dersiniz? Denediniz mi hiç böyle ad-hoc takım çözümleri?

Önce şunu netleştirelim: Ruleset nedir, niye umursuyoruz?

Ruleset’leri ilk gördüğümde — sanırım 2023 sonuydu — “yine eski branch protection’ın makyajlanmış hâli mi acaba?” diye düşündüm. Yanılmışım. Ruleset’ler, branch protection rule’ların yapamadığı şeyleri yapıyor: hiyerarşik (enterprise → organization → repository), birden fazla kural seti üst üste binebiliyor,. En önemlisi auditable. Yanı kim ne zaman ne yapmış, hepsi kayıt altında.

Bence, Peki neden önemli? Çünkü işin aslı, ekip büyüyünce o eski yöntemler hemen çuvallıyor; bir yerde geçici izin açıyorsun, başka yerde aynı kuralı kapatıyorsun, sonra da kim neyi niye yaptı diye logların içinde boğuluyorsun. Evet, tam orası biraz karışık.

Ama bir sıkıntısı vardı. Bypass yetkilendirme tarafı sadece takım ya da rol bazlıydı. Yanı diyelim ki Ayşe’nın bir hotfix için tek seferlik production branch’ine push yetkisi olması gerekiyor. Eskiden ne yapardık? Ya geçici bir takım açardık (ve sonra unutup orada bırakırdık), ya da kuralı geçici devre dışı bırakırdık (ki bu çok daha kötü bir pratik) — bence çok yerinde bir karar —. Şimdi bakınca insan “neden baştan böyle değildi?” diyor ama o zamanlar sistem öyleydi işte; bu güncellemeyle birlikte doğrudan kullanıcı eklenebiliyor.

Bu kadar mı? Değil tabii.

“Küçük bir UX değişikliği gıbı görünebilir, ama kurumsal compliance ekipleri için bu tarz bir granularity altın değerinde. Audit trail’ınızı temiz tutmanın en güvenilir yolu, bypass’ları kişiye bağlı kılmaktır.”

Kendi deneyimimden konuşuyorum, Açık konuşayım, burada beni en çok şaşırtan şey teknik taraf değil; operasyonel rahatlık öldü (kendi tecrübem). Mesela biri cuma akşamı production’a açıl müdahale edecekse, artık bütün yapıyı eğip bükmeden işi çözebiliyorsun (tabi doğru yetki modeliyle). Az önce “geçici takım” dedim ama aslında çoğu durumda o yaklaşım daha riskliydi.

Neyse uzatmayalım, konu şu: Ruleset zaten güçlüydü, şimdi bypass tarafında da daha temiz çalışıyor. Hani bazen küçük görünen değişiklikler vardır ya, sonra toplantıda herkesin yüzünü kurtarır; bu da onlardan biri gıbı duruyor (kendi tecrübem)

Bireysel Kullanıcı Bypass: Sahadan İlk İzlenim

Bu özelliği duyduğum gün, test repo’sunda hemen kurcaladım. UI tarafı fena değil; ruleset ayarlarına girince “Bypass list” kısmında artık kullanıcı, takım, role, app gıbı farklı tipleri seçebiliyorsunuz, bir de REST API. GraphQL tarafından aynı işi yapabiliyorsunuz, ki CI/CD otomasyonu döndürenler için bu baya iş görüyor (buna dikkat edin)

Hangı senaryoda kim ekleyecek?

Eh, Bence burada üç yer öne çıkıyor. Peki neden? Çünkü pratikte hep aynı dertlere çarpıyoruz, biri servis hesabı oluyor, biri geçici yetki istiyor, bir diğeri de tek kişilik özel rol gıbı davranıyor.

• Service account’lar: Release bot’larınız, deploy otomasyonu yapan account’lar. Eskiden bunlar için ayrı takım açıyorduk, açık konuşayım biraz gereksizdi. (bence en önemlisi)
• Geçici hotfix yetkisi: Cuma akşamı 23:00’te production’a girmesi gereken biri. Pazartesi yetkiyi kaldırırsınız. Bu kadar basit.
• Tek kişilik özel roller: Mesela security lead’ınız var, sadece o kişinin emergency bypass yetkisi olmalı. Başka kimseye gerek yok.

Geçen hafta bir telekom müşterimizde buna benzer bir şey yaşadık aslında. SOC ekibinden tek bir analist’in incident response sırasında belirli branch’lere yazma yetkisi gerekiyordu; eskiden ne yapıyorduk, “soc-emergency-bypass” diye takım açıp içine tek kişi koyuyorduk (sonra üç ay sonra adamın departmanı değişiyor, takım orada öylece kalıyor), şimdi direkt kişiyi ekliyorsunuz ve çıkarması da kolay oluyor. Audit log’a bakınca da kafa karışıklığı çıkmıyor.

Evet.

Türkiye’deki kurumsal yapılar açısından

Türkiye’deki — özellikle finans ve telekom tarafındaki — müşterilerimde gördüğüm şey şu: ruleset benimseme oranı hâlâ düşük, çoğu ekip klasik branch protection ile devam ediyor. Niye böyle? Çünkü BDDK denetimlerinde “bu kural ne zaman eklendi, kim ekledi, hangı onayla geldi?” sorusu geliyor ve eski yapı bu tarafta biraz cılız kalıyordu; ruleset’ler de tam bu boşluğu dolduruyor gıbı duruyor.

Bireysel kullanıcı bypass özelliği bu denetim işini de kolaylaştırıyor (en azından benim deneyimim böyle). Takım listesini didik didik etmek yerine doğrudan “bu kişinin neden bypass yetkisi var?” sorusunun cevabını ruleset üzerinde görüyorsunuz, yanı işin aslı daha az dolaşıp daha net bakıyorsunuz. Sade mi? Evet. Ama bazen aradığımız şey tam da bu oluyor.

Branch Yeniden Adlandırma: Neden Bu Kadar Önemli?

Şimdi ikinci parçaya gelelim. Bence asıl hayatı nokta burası. Şöyle bir durum düşünün: organization seviyesinde bir ruleset var ve main branch’ını koruyor (evet, doğru duydunuz). Repository admin’i de bir gün çıkıp diyor ki, “biz hâlâ master kullanıyoruz, hadi main’e geçelim”. Eskiden iş pek de öyle rahat yürümüyordu, hatta biraz sürüncemede kalıyordu.

Evet, doğru duydunuz.

Doğrusu, Maalesef. Bu konuyla ilgili Foundry Hosted Agents: MAF Ajanını Production’a Almak yazımıza da göz atmanızı tavsiye ederim.

Repository admin’i bunu tek başına yapamıyordu. Çünkü branch ismi — kendi adıma konuşayım — değişince ruleset kapsamı da etkilenebiliyor, dolayısıyla organization ya da enterprise admin’ının devreye girmesi gerekiyordu. Yanı basit görünen bir rename için bilet açıyordunuz, sonra bekliyordunuz, sonra bir daha bekliyordunuz. Büyük ortamlarda bu iş bazen haftalar sürüyor — abartı değil.

Yeni mantık nasıl çalışıyor?

GitHub burada şöyle bir çizgi çekmiş: Eğer yeni branch adı, eski ada uygulanmış olan TÜM ruleset’lerin içinde kalıyorsa, repo admin kendi başına rename yapabiliyor. Ama yeni işim herhangi bir ruleset’in dışına taşıyorsa, işlem duruyor. Ilgili seviyedeki admin’in onayı gerekiyor (bizzat test ettim). Kulağa basit geliyor, ama işin aslı baya yerinde bir ayrım olmuş. github konusundaki yazımız yazımızda bu konuya da değinmiştik.

Bir tabloyla toparlayayım:

Eski Branch	Yeni Branch	Ruleset Pattern	Sonuç
master	main	main, master, release/*	✅ Repo admin yapabilir
release/v1	release/v2	release/*	✅ Repo admin yapabilir
main	trunk	main, master	❌ Bloklu — Org admin gerekir
feature/x	main	main	❌ Daraltma değil genişletme — admin gerekir

Açık konuşayım, Mantık aslında şu: Kapsam aynı mı kalıyor? Evetse serbest bırakıyorlar. Değişiyorsa kapı kapanıyor. Bu kadar net. Bir de ufak not düşeyim; organization ve enterprise admin’leri isterlerse bu özelliği settings’ten kapatabiliyorlar. Yanı kontrol büyük ölçüde aşağıya inmiş değil, üst tarafta hâlâ düğme duruyor (buna dikkat edin)

Neyse uzatmayalım, olayın özü bu. Bu konuyla ilgili Bankacılıkta Customer 360: Azure DocumentDB ile Pratik Yol yazımıza da göz atmanızı tavsiye ederim.

Pratik Bir Örnek: master → main Geçişi

Bu işin en sık görülen senaryosu bu, yanı master’dan main’e geçiş (en azından benim deneyimim böyle). Hani hâlâ yapmayan ekipler var ya, şaşırıyorum açıkçası; ama var işte, özellikle eski repo’larda bunu çok görüyorsunuz. Şöyle ilerleyebilirsiniz: Bu konuyla ilgili mssql-python’da Apache Arrow Desteği: Sahadan Notlar yazımıza da göz atmanızı tavsiye ederim.

# Önce ruleset'in main ve master'ı kapsadığından emin olun
# GitHub UI: Settings → Rules → Rulesets → Edit
# Sonra GitHub CLI ile rename:
gh api repos/ORG/REPO/branches/master/rename \
-f new_name='main' \
-X POST
# Yerel repo'ları güncelleyin (ekibinize duyurun):
git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

Burada küçük ama can sıkan bir detay var: CI/CD pipeline’larınız, deployment script’leriniz, Azure DevOps ya da Jenkins entegrasyonlarınız varsa, oralarda da “master” diye gömülü referanslar kalabiliyor, ve sonra biri gelip neden build patladı diye bakıyor. AZ-400 sınavına hazırlanırken buna benzer bir şeyle karşılaşmıştım — hardcoded branch ismi ufak bir ayrıntı gıbı duruyor ama işi baya karıştırabiliyor.

İlgili konuda

Branch yönetimi ve CI/CD entegrasyonu tarafında daha önce GitHub rate_limit API: code_scanning_upload Alanı Kalkıyor yazısında benzer breaking change’lerden bahsetmiştim. GitHub’ın bu tür governance değişikliklerinde izlediği çizgi genelde aynı: önce duyuru geliyor, sonra opt-in açılıyor, en son default hâle dönüyor. Açık konuşayım, fena değil bu yaklaşım. Bu konuyla ilgili VS Code Nişan Sürümleri: Copilot’ta Neler Değişti? yazımıza da göz atmanızı tavsiye ederim.

Enterprise vs Startup: Kimin İçin Ne Anlam İfade Ediyor?

Bakın şimdi, açık konuşayım: bu özellik herkese aynı etkiyi yapmayacak. 5 kişilik bir startup’sanız, büyük ihtimalle bypass list’inizde kimse yoktur zaten; kuralları o kadar sıkı kurmuyorsunuz. Ama 500+ developer’lı bir kurumsal yapıda iseniz, iş değişiyor, çünkü bu güncelleme operasyon tarafındaki yükü baya azaltabiliyor.

Küçük ekipseniz

Repository ruleset’i kullanmıyorsanız, bu yazıyı bitirince gidip bir bakın derim. Ücretsiz hesapta bile public repo’larda var. Branch protection’dan ruleset’e geçiş de öyle göz korkutan bir şey değil — UI üzerinden 10 dakikalık iş, hadi bilemediniz biraz daha fazla sürer. Bireysel bypass özelliği sizin için çok kritik olmayabilir,. Branch rename özgürlüğü yine de zaman kazandırıyor, özellikle de küçük ekipte “kim neyi neden değiştirdi” tartışması uzuyorsa.

Kurumsal yapıdaysanız

İşte burada mevzu biraz kıvrılıyor. Enterprise plan kullanıyorsanız, bu güncelleme bence üç şeyi tekrar masaya koymanızı gerektiriyor, çünkü kağıt üstünde basit duran şeyler pratikte bazen can sıkabiliyor:

1. Mevcut bypass takımlarınızı denetleyin. Tek kişilik takım açılmış mı? Muhtemelen açılmıştır. Bunları ayıklama zamanı geldi.
2. Branch naming policy’nizi gözden geçirin. Ruleset pattern’larınız fazla dar işe, repo admin’leri yine duvara tosluyor. release/* gıbı geniş pattern’lar çoğu senaryoda daha rahat ettiriyor.
3. “Disable rename” ayarını kullanma kararı verin. Bazı sektörlerde — özellikle finansta — branch rename işleminin audit tarafı ayrıca düşünülmek zorunda kalabiliyor. O durumda bu özelliği kapatmak daha mantıklı olabilir.

Yaşadığım Bir Sorun ve Çözümü

Test ortamında bir şey fark ettim, ama ilk anda önemsemedim. Branch rename komutu 403 dönüyordu, halbuki ruleset pattern’ım yeni ismi de kapsıyordu; yarım saat kafa patlattıktan sonra işin aslı ortaya çıktı, enterprise seviyesinde başka bir ruleset daha varmış. Onun pattern’ı dar tutulmuştu. Yanı sadece organization tarafına bakmak yetmiyor, enterprise -> organization -> repository zincirinin tamamını kontrol etmek gerekiyor.

Peki çözüm ne? GitHub’ın ruleset insights sayfasından “applicable rules” view’ına bakmak. Orada hangı ruleset’lerin hangı branch’e uygulandığını net biçimde görüyorsunuz, hani bazen gözden kaçan detay tam da bu oluyor; dokümantasyonda var ama biraz kenarda kalmış, açık konuşayım ben de ilk bakışta atlamıştım.

Eksik Yönü Var mı?

Olmaz ölür mu. Bir kere şunu net söyleyeyim: bireysel bypass tarafı sadece repository-level ruleset’ler için açılmış, organization ya da enterprise seviyesinde işe hâlâ takım. Role bazlı düşünmek zorundasınız; açık konuşayım, büyük yapılarda insanın canını biraz sıkıyor bu, çünkü asıl dert çoğu zaman zaten organization katmanında çıkıyor (ben de ilk duyduğumda şaşırmıştım)

Bir de işin şu tarafı var: bireysel kullanıcı bypass’larında “süre” diye bir şey yok, yanı “bu kişiye 24 saatliğine bypass ver” gıbı bir seçenek gelmemiş; manuel ekle, sonra manuel çıkar. Evet, baya düz. Time-bound access ileride gelirse iyi ölür, ama şu an yok. Entra Agent ID GA: Sponsor Grup Tipi Kısıtlaması Geldi yazımda bahsettiğim PIM (Privileged Identity Management) mantığının GitHub tarafına da taşınması lazım bence, hani Microsoft tarafında bu konu oturmuş, GitHub tarafında işe biraz eksik kalmış gıbı duruyor.

Aksiyon Listesi: Hemen Ne Yapmalısınız?

Lafı uzatmadan, bu yazıdan sonra elinizi taşın altına koyup yapabileceğiniz somut adımlar şunlar:

1. Ruleset envanteri çıkarın. Org’unuzdaki büyük çoğunluk ruleset’leri tek tek listeleyin. gh api ile bunu script’e dökmek baya iş görüyor, yanı elle uğraşmaya pek gerek kalmıyor.
2. Bypass list’leri tarayın. Tek kişilik takımları bulun. Bunları “individual user” olarak migrate edin, çünkü yoksa liste şişiyor ve kim neyi neden bypass ediyor, bir süre sonra karışıyor. (bu kritik)
3. master branch’i olan repo’ları bulun. Hâlâ master kullanan repo’larınız varsa, main’e geçiş için bir gün belirleyin. Evet, küçük gıbı duruyor ama sonra işim karmaşası can sıkabiliyor.
4. Audit log’u kontrol etmeyi unutmayın. Bypass kullanımı ne sıklıkta oluyor? Çok sık görüyorsanız, belki de kural fazla sıkıdır; açık konuşayım, orada ayar biraz sert kalmış olabilir.
5. Enterprise admin’inizle konuşun. “Disable rename” ayarının açık mı kapalı mı olacağına birlikte karar verin. Bu kısım bazen önemsiz gıbı geliyor ama sonradan sürpriz çıkarmayı da seviyor.

Bu arada GitHub’ın governance tarafıyla ilgili biraz daha kurcalamak isterseniz, GitHub MCP Server’da Secret Scanning GA: Sahadan Notlar ve Defender for Cloud + GHAS Entegrasyonu: Code-to-Cloud GA yazılarına da göz atabilirsiniz. Birbirini tamamlayan konular bunlar, hani birini okuyunca öteki biraz daha anlam kazanıyor gıbı.

Sıkça Sorulan Sorular

Repository ruleset ile branch protection rule arasındaki fark ne?

Branch protection rule aslında eski model — hani sadece branch bazlı çalışıyor, repository seviyesinde kalıyor. Ruleset işe çok daha modern: hiyerarşik yapısı var (enterprise/org/repo), birden fazla pattern’i destekliyor, audit log’u daha zengin, ve bireysel kullanıcı bypass’ı gıbı güzel özellikler sunuyor. Bence yeni projelerde kesinlikle ruleset kullanın, branch protection’ı artık emekli edin.

Bunu biraz açayım.

Bireysel kullanıcı bypass’ı service account’lar için de çalışıyor mu?

Hani, Evet, çalışıyor. GitHub’ın gözünde service account da bir user account, yanı ayrım yok. Eskiden bu account’ları gruba almak için ayrı takım açmak gerekiyordu. Artık doğrudan ruleset bypass listesine ekleyebilirsiniz. Hani ne farkı var diyorsunuz, değil mi? Açıkçası bot account’larınız için çok pratik bir çözüm bu.

master’dan main’e geçerken açık pull request’ler ne oluyor?

GitHub’ın rename API’si açık PR’ları otomatik olarak yeni branch ismine yönlendiriyor. Yanı PR’lar kapanmıyor, kaybolmuyor, merak etmeyin. Ama lokal repo’lardaki “master” reference’ları manuel güncellenmeli — bunun için git branch -m komutu var. Bir de CI/CD pipeline tanımlarınızı kontrol etmeyi sakın unutmayın, tecrübeme göre en çok orası atlanan yer oluyor.

Bunu biraz açayım.

Bu özellik GitHub Enterprise Server’da da var mı, sadece GitHub.com’da mı?

Şu an önce GitHub.com’a geldi. Enterprise Server tarafına genelde 1-2 release sonra iniyor bu tarz özellikler, yanı aşağı yukarı 3-6 ay beklemek gerekiyor. GHES kullanıcısıysanız release notes’ları takıp edin — muhtemelen 3.18 ya da 3.19 sürümlerinde göreceğiz.

Org admin “rename”i kapatırsa repo admin’ler ne yapacak?

Klasik akışa dönmek zorunda kalacaklar, yanı branch rename için organization admin’ine ticket açıp beklemek. Bu yüzden aslında bu ayarın açık tutulması gereksiz governance yükünü epey azaltıyor. Ama denetim gereksinimleriniz katıysa kapatmak da makul bir karar tabii, bence duruma göre değerlendirmek lazım.

Şimdi gelelim işin can alıcı noktasına.

Kaynaklar ve İleri Okuma

Şöyle ki, GitHub Changelog: Repository rulesets — User bypass and branch renaming

GitHub Docs: About rulesets

Kısacası, şöyle ki, GitHub REST API: Repository Rules (buna dikkat edin)