Repository Kuralları Nasıl Yönetilmeli? Branch Protection, Ruleset ve AI Agent Yetkilerini Birlikte Planlamak

Kısa özet Repository güvenliği yalnızca main branch’ine direct push’u kapatmaktan ibaret değildir. Sağlıklı bir governance modeli; pull request zorunluluğu, insan onayı, CODEOWNERS, required status checks, force-push kısıtları, bypass yetkileri, security/code-quality gate’leri ve AI coding agent’ların hangi branch ve işlemlere erişebileceğini birlikte ele almalıdır. GitHub’da klasik branch protection ile rulesets birlikte çalışabilir. Ancak aralarında önemli bir fark vardır: aynı branch için yalnızca tek branch protection rule uygulanırken birden fazla ruleset aynı anda uygulanabilir; kurallar katmanlanır ve çakışan koşullarda daha kısıtlayıcı olan sonuç geçerli olur. (GitHub Docs) AI agent’ların repository’ye kod yazabildiği güncel geliştirme modelinde asıl hedef: “Agent kod yazabiliyor mu?” değil, “agent’ın yazdığı kod hangi kontrolleri geçmeden güvenilir branch’e ulaşamaz?” sorusunu cevaplamaktır.

Kısa doğrudan cevap

Çoğu production repository için güçlü bir temel şu olabilir:

Developer / AI Agent ↓ Feature / Agent Branch ↓ Pull Request ↓ Required CI ↓ Security / Quality Checks ↓ CODEOWNERS gerekiyorsa review ↓ Human Approval ↓ Merge Queue gerekirse ↓ Protected main Minimum olarak şu kontroller değerlendirilmelidir: Pull request zorunlu En az bir insan approval Required status checks Force push kapalı Branch deletion kontrollü Hassas alanlarda CODEOWNERS Yeni commit sonrası eski approval’ın geçerliliği Bypass yetkilerinin minimum tutulması AI agent’a main üzerinde özel ayrıcalık verilmemesi Ruleset değişikliklerinin ve bypass’ların audit edilmesi GitHub da kurumsal Copilot rollout rehberinde önemli codebase’ler için pull request zorunluluğu, en az bir approval, force-push engeli ve hassas alanlarda CODEOWNERS kullanımını temel governance yaklaşımı olarak öneriyor. (GitHub Docs)

Branch protection neyi çözüyor?

Branch protection belirli branch’lerin kontrolsüz değiştirilmesini engeller. Örneğin: main production release/* üzerinde:

• PR zorunlu,
• review zorunlu,
• status checks zorunlu,
• signed commit zorunlu,
• force push yasak,

deletion yasak gibi kurallar uygulanabilir. GitHub’ın güncel branch protection özellikleri ayrıca:

• conversation resolution,
• linear history,
• merge queue,

başarılı deployment gereksinimi

gibi koşullar da sunuyor. (GitHub Docs)

Sadece main branch'e direct push'u kapatmak neden yetmez?

Şu politika:

main direct push = disabled iyi bir başlangıçtır. Ama PR: test çalışmadan + kimse review etmeden + security scan yapılmadan merge edilebiliyorsa güvenlik sınırı oldukça zayıftır.

Repository governance katmanlı düşünülmelidir:

• Kim değiştirebilir?

↓

Nasıl değiştirebilir?

↓

Kim onaylar?

↓

Hangi testler geçmeli?

↓

Hangi dosyalarda ekstra review gerekir?

↓

Kim kuralları bypass edebilir?

Ruleset ile branch protection arasındaki fark nedir?

GitHub ikisini de destekliyor fakat rulesets daha esnek bir politika katmanı sunuyor. Branch protection Belirli branch veya branch pattern’ini korur. Ancak GitHub’a göre aynı branch için yalnızca tek branch protection rule geçerli olabilir. Birden fazla pattern eşleşmesi varsa hangi protection’ın uygulanacağını yönetmek daha zor hale gelebilir. (GitHub Docs) Ruleset Named policy setidir. Örneğin: Baseline Security Critical Production Payment Service AI Agent Guardrails gibi ayrı ruleset’ler oluşturulabilir. Birden fazla ruleset aynı branch’e uygulanabilir. GitHub bunları katmanlar ve aynı kural farklı sıkılıkta tanımlanmışsa daha kısıtlayıcı sonuç uygulanır. (GitHub Docs) Örnek katmanlama Organizasyon genelinde: Baseline Ruleset ---------------- PR required 1 approval force push blocked CI required Payment repository’sinde ayrıca: Payment Ruleset --------------- 2 approvals CODEOWNERS security checks uygulanabilir. Sonuç: Payment/main = Baseline + Payment-specific protections olur. Repository-level kural enterprise baseline’ı gevşetmez; ek kısıt getirebilir. GitHub da Copilot governance rehberinde merkezi baseline üzerine daha spesifik repository ruleset’leri eklenmesini öneriyor. (GitHub Docs)

Neden ruleset yaklaşımı büyüyen organizasyonlarda daha kullanışlı?

20 repository olduğunda tek tek:

repo 1 settings repo 2 settings repo 3 settings ... yönetmek kolaydır. 200 repository olduğunda ise configuration drift başlar: Repo A → 1 approval Repo B → approval yok Repo C → force push açık Repo D → CI required değil Ruleset ile ortak bir baseline daha merkezi uygulanabilir. GitHub Team ve Enterprise organizasyonlarında organization-level ruleset’ler birden fazla repository’yi hedefleyebilir. (GitHub Docs) Repository'leri aynı güvenlik seviyesinde görmek de doğru değil Bir organizasyonda: marketing-site internal-dashboard customer-api authentication billing infrastructure aynı riskte değildir. Bu nedenle: Global baseline + risk bazlı ek kurallar modeli daha sağlıklıdır. Önerilen üç seviye Seviye 1 — Baseline Bütün production repository’ler. PR required 1 approval CI required force push blocked Seviye 2 — Critical Örneğin: backend auth billing customer data. Ek olarak: CODEOWNERS security checks stale approval dismissal Seviye 3 — Highly Critical Örneğin: production infrastructure IAM deployment payment. Ek olarak: 2 approvals specialized team review deployment gate merge queue restricted bypass Bu sınıflandırma InoviqLab teknik önerisidir.

Pull request zorunlu olmalı mı?

Production branch’lerinde çoğunlukla evet. Ruleset’in: Require a pull request before merging kuralı doğrudan branch’e kontrolsüz değişiklik girmesini engelleyebilir. Ancak dikkat: PR zorunlu olması tek başına approval zorunlu olduğu anlamına gelmez.

GitHub ruleset’te PR zorunlu tutulurken ayrıca required approval sayısının belirlenmesine izin veriyor. (GitHub Docs)

Minimum kaç approval gerekli?

Tek evrensel rakam yoktur. Pratik model: Repository Approval Marketing 1 Normal SaaS 1 Backend core 1–2 Billing/Auth 2 düşünülebilir Infrastructure 2 + owner Ancak: 5 approval koymak otomatik olarak daha güvenli değildir. Review işlemi formaliteye dönüşürse: LGTM LGTM LGTM güvenlik değeri düşebilir.

En önemli review seçeneklerinden biri: son push'u kim onaylıyor?

Şu senaryoyu düşünün:

PR açıldı ↓ Human approved ↓ Developer/agent yeni commit push etti ↓ Merge İlk reviewer yeni commit’i görmemiş olabilir. GitHub rulesets:

• yeni commit geldiğinde stale approval’ları dismiss etmeyi,

veya son reviewable push’un onu yapan kişiden farklı biri tarafından onaylanmasını

destekliyor. (GitHub Docs)

AI agent döneminde bu neden daha önemli?

Agent review sonrası:

17 dosya değiştirebilir ve eski approval teknik olarak önceki diff’e verilmiştir. Bu nedenle hassas codebase için: Review’dan sonra değişiklik gelirse yeniden insan kontrolü güçlü bir varsayılandır. GitHub Copilot governance dokümantasyonu da PR hijacking riskine karşı yeni commit sonrasında eski approval’ların dismiss edilmesini öneriyor. (GitHub Docs)

CODEOWNERS neyi çözer?

CODEOWNERS belirli dosya ve klasörlerin sorumlularını tanımlar. Örneğin: /.github/workflows/ @platform-team /infrastructure/ @devops-team /auth/ @security-team /billing/ @billing-team Pull request bu alanlara dokunduğunda ilgili owner review için çağrılabilir.

Branch protection veya ruleset üzerinden code-owner approval zorunlu hale getirilebilir. (GitHub Docs)

AI agent için CODEOWNERS neden özellikle değerli?

AI agent:

src/components/Button.tsx değiştiriyorsa normal review yeterli olabilir. Ama: .github/workflows/deploy.yml değiştiriyorsa farklı risk vardır. Çünkü workflow değişikliği dolaylı olarak: CI ↓ Secrets ↓ Production erişimini etkileyebilir. Benzer biçimde: terraform/ auth/ database/migrations/ daha uzman review gerektirebilir.

CODEOWNERS dosyasının kendisini kim koruyor?

Bu kritik fakat sık atlanan noktadır. Eğer agent veya developer: CODEOWNERS dosyasını değiştirerek kendisini review kapsamından çıkarabiliyorsa sistem zayıflar. GitHub, repository’yi daha güçlü korumak için CODEOWNERS dosyasının kendisine veya bulunduğu .github/ dizinine de owner tanımlanmasını öneriyor. (GitHub Docs) Örneğin: /.github/ @platform-security yaklaşımı kullanılabilir. Ruleset'te artık path bazlı required reviewer da mümkün GitHub’ın güncel ruleset seçenekleri belirli team’lerin yalnızca belirli file pattern’leri değiştiğinde approval vermesini gerektirebiliyor. Örneğin kavramsal olarak: /infrastructure/ → platform team approval /billing/ → billing team approval Ruleset API dokümantasyonunda bu required_reviewers özelliği halen beta olarak işaretlenmiştir; dolayısıyla ürün davranışı değişebilir. (GitHub Docs) Bu model CODEOWNERS’a alternatif veya tamamlayıcı olabilir.

Required status check ne işe yarar?

Pull request review insani kontroldür. CI ise deterministik kontrol sağlar. Örneğin: typecheck lint unit integration security build check’leri required yapılabilir.

Hepsi başarılı olmadan merge engellenir. (GitHub Docs)

Her CI check required olmalı mı?

Hayır. Örneğin: preview deploy bazen informative olabilir. Ama: typecheck critical tests security validation hard gate olabilir. İyi governance: Her dashboard sinyalini merge blocker haline getirmek değildir. Çok sayıda flaky required check geliştiricilerin bypass aramasına yol açabilir. Required status check için az bilinen güvenlik noktası GitHub dokümantasyonuna göre repository üzerinde write yetkisi bulunan kişi veya entegrasyonlar status oluşturabilir. Bu nedenle required check eklerken mümkünse: Expected source → belirli GitHub App seçilebilir. Başka actor veya integration aynı status adını gönderirse merge şartı karşılanmış sayılmaz. (GitHub Docs) Bu özellikle: security-check production-validation gibi kritik gate’lerde önemlidir.

Sadece check adına güvenmek neden zayıf olabilir?

Şöyle bir required check düşünün:

security Eğer trusted source tanımlı değilse yanlış entegrasyonun aynı check ismini üretmesi governance açısından kafa karıştırabilir. Daha kontrollü: security + expected GitHub App modelidir. Code scanning ve code quality de ruleset'e bağlanabilir GitHub’ın güncel ruleset rule’ları arasında: required code scanning results required code quality results code coverage restrictions bulunuyor. (GitHub Docs) Böylece: Tests green yanında: Security findings acceptable Code quality criteria acceptable gibi kurallar da merge governance’a eklenebilir.

Her repository'ye bütün gate'leri açmalı mısınız?

Hayır. Örneğin: Marketing repository Build Lint 1 approval SaaS backend Build Tests Code scan 1 approval Payment Build Tests Integration Security Code owner 2 approvals Risk bazlı governance daha sürdürülebilirdir.

Force push neden kapatılmalı?

Force push Git history’yi değiştirebilir. Protected production branch’te: git push --force

commit history ve review zincirini bozabilir.

GitHub protected branch’lerde force push’u varsayılan olarak engeller; rulesets tarafında da Block force pushes kuralı kullanılabilir. (GitHub Docs) GitHub, AI-enabled codebase governance için de force push’un kapatılmasını temel baseline’lardan biri olarak öneriyor. (GitHub Docs) Branch deletion da kontrollü olmalı Örneğin: production release main yanlışlıkla silinmemelidir. Rulesets: Restrict deletions ile branch/tag deletion’ını bypass yetkili actor’larla sınırlandırabilir. (GitHub Docs) Bypass yetkisi repository governance'ın en kritik noktalarından biridir Dünyanın en güçlü ruleset’ini kurup: admins → always bypass developers → bypass apps → bypass yaparsanız governance değeri düşer. Bypass: normal çalışma yolu değil, istisna mekanizmasıdır.

GitHub ruleset bypass listesine kimler eklenebilir?

Repository/organizasyon yapısına göre:

• belirli roller,
• teams,
• GitHub Apps,

Dependabot gibi actor’lar eklenebilir. Organization-level ruleset’lerde GitHub güncel olarak Copilot cloud agent’ı da bypass listesine eklenebilen actor’lar arasında gösteriyor. (GitHub Docs) Bu özellik: “Copilot’u bypass’a eklemelisiniz.” anlamına gelmez. Tam tersine AI agent governance’ında bu bir yüksek riskli exception olarak değerlendirilmelidir.

AI agent'a bypass yetkisi vermek mantıklı mı?

Varsayılan:

❌ Hayır olmalıdır. Çünkü güçlü model: Agent kod yazar ↓ Ruleset onu sınırlar iken bypass sonrası: Agent ↓ Guardrail exception oluşabilir. Özel otomasyon ihtiyacı gerçekten gerektiriyorsa kapsamı minimum tutulmalı ve bypass activity audit edilmelidir.

“For pull requests only” bypass ne işe yarıyor?

GitHub ruleset bypass ayarında belirli actor’lara:

Always allow yerine: For pull requests only seçeneği verilebiliyor. Bu durumda actor doğrudan push yerine PR açmak zorunda kalıyor; değişiklik için PR ve audit trail oluşuyor. (GitHub Docs) Genel olarak exception gerekiyorsa: Doğrudan branch bypass yerine PR trail’ini koruyan dar exception daha güçlü governance sağlar.

GitHub Copilot cloud agent varsayılan olarak nasıl sınırlandırılıyor?

GitHub’ın 23 Ağustos 2026 itibarıyla belgelenmiş modeli oldukça net. Copilot cloud agent: yalnızca write erişimi olan kullanıcılar tarafından tetiklenebilir, yalnızca tek çalışma branch’ine push edebilir,

• çoğu görevde copilot/ branch’i oluşturur,
• repository branch protections ve required checks’e tabidir,
• kendi PR’ını ready-for-review yapamaz,
• approve edemez,
• merge edemez,

insan review’u gerektirir. (GitHub Docs) Bu, agent permission ile repository governance’ın birlikte nasıl çalışabileceğine iyi bir örnektir.

Agent branch'i neden önemli?

Agent’a:

main write vermek yerine: copilot/task-123 gibi çalışma branch’i kullanmak risk alanını küçültür. Kod: agent branch içinde değişebilir. Ama trusted branch’e geçiş: PR + CI + Human ile olur.

Copilot kendi PR'ını merge edebilir mi?

Hayır. GitHub güncel dokümantasyonuna göre cloud agent’ın oluşturduğu draft PR insan tarafından review edilip merge edilmelidir; agent PR’ı approve veya merge edemez. (GitHub Docs) Bu sınır önemli: Kod üreten actor ile kodu kabul eden actor ayrılmıştır.

Agent görevi isteyen kişi kendi PR'ını approve edebilir mi?

GitHub Copilot cloud agent özelinde GitHub, agent’a işi veren kullanıcının o agent PR’ını approve etmesini engelleyerek required-approval modelini koruyor. (GitHub Docs) Bu iyi bir segregation-of-duties örneğidir: User requests ↓ Agent changes ↓

Different human reviews

Agent'ın workflow değiştirmesi daha riskli mi?

Evet. Örneğin Copilot: .github/workflows/deploy.yml değiştirdi. Bu PR merge olmadan önce workflow kodunun çalışması bile güvenlik riski yaratabilir çünkü workflow secrets veya privileged runner kullanabilir. GitHub bu nedenle Copilot cloud agent kodundan tetiklenen workflow’ları varsayılan olarak bir write yetkili kullanıcı Approve and run workflows diyene kadar çalıştırmıyor. Bu davranış ayrıca konfigüre edilebiliyor. (GitHub Docs) Hassas AI config dosyaları da korunmalı Örneğin: AGENTS.md .github/copilot-instructions.md MCP config agent setup workflow agent davranışını etkileyebilir. Bunların değiştirilmesi: source code değişikliği kadar kritik olabilir. Bu nedenle InoviqLab önerisi: AI instructions MCP config workflow config CODEOWNERS alanlarında ayrı owner/review kuralı düşünmektir. Instruction güvenlik kontrolünün yerine geçmez Şunu yazmak: “main branch'e yazma” faydalıdır. Ama: ruleset bunu gerçekten engelliyor çok daha güçlüdür. Aynı şekilde: “workflow dosyasını değiştirme” yerine: workflow path → platform-team approval teknik enforcement sağlar. Kural: Agent instruction davranışı yönlendirir; repository ruleset davranışı sınırlar.

Ruleset'i bir anda Active yapmak doğru mu?

Her zaman değil. GitHub Enterprise Cloud rulesets: Active Evaluate Disabled enforcement durumlarını destekliyor. Evaluate modunda kural merge/push’u engellemez ancak hangi işlemlerin kurala takılacağını Rule Insights üzerinden görebilirsiniz. (GitHub Docs)

Evaluate mode neden çok değerli?

Örneğin şirket genelinde:

2 approval zorunlu yapacaksınız. Direkt Active: 50 repository ↓ 20 takım bloklandı sonucu oluşturabilir. Daha iyi: Evaluate ↓ 2 hafta gözlem ↓ Fail / bypass analizi ↓ Eksikleri düzelt ↓ Active olabilir. Bu model governance rollout riskini azaltır.

Rule Insights ne gösteriyor?

GitHub 12 Ağustos 2026’da organization-level Rule Insights’ı public preview olarak duyurdu. Dashboard:

• allowed,
• failed,

bypassed ruleset evaluation’larını organizasyon genelinde gösterebiliyor. Ayrıca:

• en çok bypass yapılan repository’ler,
• branch,
• ruleset,

tarih bazında filtreleme ve CSV export bulunuyor. (The GitHub Blog) Bu özellikle governance’ın kağıt üzerinde mi yoksa gerçekten uygulanıyor mu olduğunu görmek için değerlidir.

Bypass sayısını KPI yapmalı mıyız?

Tek başına değil. Örneğin: 10 bypass çok olabilir. Ama release incident sırasında bilinçli emergency deployment olabilir. Daha güçlü metrikler: bypass count + bypass reason + actor + repository + ruleset + trend birlikte değerlendirilmelidir. Sürekli bypass edilen kuralın iki olası açıklaması vardır Açıklama 1 Takım policy’yi takip etmiyor. Açıklama 2 Policy gerçek development akışına uygun değil. İyi governance: “Bypass yaptın, hata.” demek yerine bypass nedenini analiz eder.

Admin'ler kurallardan muaf olmalı mı?

Varsayılan karar olarak dikkatle değerlendirilmelidir. Branch protection’larda administrator/bypass role davranışı konfigüre edilebilir. GitHub ayrıca branch protection’ı admin’lere de uygulama seçeneği sağlar. (GitHub Docs) Production-critical repository için:

admin = kuralsız

çok geniş bir trust modelidir. Emergency access gerekiyorsa daha görünür ve audit edilebilir bypass modeli daha sağlıklı olabilir. Bypass için break-glass modeli Örneğin: Normal: No bypass Incident: Specific platform/security role ↓ Temporary exception ↓ Audit ↓ Post-incident review Bu InoviqLab governance önerisidir. Amaç kimsenin emergency değişiklik yapamaması değil; emergency değişikliğin istisna olarak görünür olmasıdır.

Merge queue ne zaman gerekir?

Yoğun repository’de şu problem oluşabilir:

PR A → CI green PR B → CI green A merge ↓ main değişti ↓ B eski main'e göre test edilmişti GitHub merge queue: PR’ı güncel target branch ve sıradaki diğer PR’larla birlikte test eder, gerekli check’ler geçerse merge eder,

yüksek merge hacminde developer’ın sürekli branch update edip CI tekrar beklemesini azaltabilir. (GitHub Docs)

Her repo merge queue kullanmalı mı?

Hayır. Günde: 2 PR merge edilen repository’de ekstra karmaşıklık olabilir. Ama: 50–100 PR/day gibi yoğun default branch’lerde daha değerlidir. AI agent'lar merge hacmini artırırsa merge queue daha değerli hale gelebilir AI coding agent’lar: PR üretim kapasitesi ↑ yaratabilir. Eğer aynı sayıda insan daha fazla PR oluşturabiliyorsa: merge contention ↑ CI load ↑ oluşabilir. Bu durumda merge queue: yalnızca developer convenience değil, branch stability mekanizması haline gelebilir. Bu yorum InoviqLab değerlendirmesidir.

Required deployment gate ne işe yarar?

GitHub rules/branch protection ile:

staging deployment başarılı olmadan merge engellenebilir. (GitHub Docs) Özellikle: infrastructure deployment configuration critical frontend/backend repository’lerinde değerlendirilebilir. Ancak staging’in kendisi flaky ise bütün development akışını kilitleyebilir.

Repository kuralları ne zaman fazla olur?

Şu yapı:

14 required check 4 approval 3 CODEOWNER staging security manual QA merge queue her basit değişiklik için uygulanırsa developer experience zarar görebilir. Sonuç: Bypass culture oluşabilir. Governance hedefi: maksimum kural değil, risk için gereken minimum etkili kontrol olmalıdır. Örnek repository policy — Normal SaaS Target: main Rules:

• Pull request required
• 1 human approval
• Required status checks:
• typecheck
• unit-test
• build
• Block force pushes
• Block deletion
• Resolve conversations

Örnek repository policy — Kritik backend Target: main Rules:

• Pull request required
• 2 approvals
• Require Code Owners
• Dismiss stale approvals
• Required checks:
• typecheck
• unit
• integration
• security
• build
• Block force push
• Block deletion

Örnek repository policy — Infrastructure Target: main Rules:

• Pull request required
• 2 approvals
• Platform CODEOWNER
• Required security checks
• IaC validation
• Staging/plan validation
• No normal bypass
• Force push blocked

Bu üç policy örneği InoviqLab önerisidir; GitHub’ın zorunlu preset’leri değildir.

AI agent için ayrıca ne eklenmeli?

Agent repository’de aktifse:

Agent: feature branch only main: PR required AI-specific config: owner protected workflow changes: platform review security-sensitive areas: CODEOWNERS final merge: human modeli düşünülebilir. Copilot cloud agent zaten kendi tarafında single-branch ve human-review sınırları uygular; ancak repository governance agent dışındaki kullanıcı ve otomasyonları da korumalıdır. (GitHub Docs) Ruleset tasarımında 5 ayrı actor düşünün Repository yalnızca insan geliştiriciler tarafından değiştirilmez.

1. Developer

Normal PR.

2. Administrator

Emergency işlemler.

3. CI/CD App

Status ve automation.

4. Dependabot

Dependency updates.

5. AI Agent

Agent-authored code.

Her biri için şu soru sorulmalıdır:

• Bu actor hangi kuralları gerçekten bypass etmek zorunda?

Çoğu durumda cevap:

Hiçbirini olabilir. Bot olduğu için bypass verilmemeli Şu varsayım tehlikelidir: “Bu otomasyon, güvenlidir.” Bot/app compromise olabilir. Yanlış konfigüre olabilir. AI agent yanlış karar verebilir. Dolayısıyla: human bot AI fark etmeksizin least privilege uygulanmalıdır. Repository governance değişiklikleri de code change kadar kritik olabilir Şunlardan biri değişirse: Required reviews 2 → 0 Security check kaldırıldı Admin bypass açıldı CODEOWNERS silindi hiçbir application code değişmeden güvenlik seviyesi düşebilir. Bu nedenle: Governance configuration da güvenlik konfigürasyonudur. Audit edilmelidir. GitHub Rule Insights ve audit sistemleri ruleset bypass ve policy davranışlarının görünürlüğünü artırabilir. (GitHub Docs) Repository Governance Kontrol Listesi Branch main / production branch korumalı. Direct push ihtiyacı değerlendirildi. Force push kapalı. Deletion kontrollü. Release branch’leri ayrıca değerlendirildi. Pull Request PR zorunlu. Required approval sayısı riskle uyumlu. Son push sonrası review politikası tanımlı. Conversation resolution gerekiyorsa aktif. Merge yöntemi belirli. CODEOWNERS Hassas klasörler owner’a sahip. Workflow dosyaları korunuyor. Infrastructure korunuyor. Auth/payment gibi alanlar korunuyor. CODEOWNERS dosyasının kendisi korunuyor. CI Required checks tanımlı. Type-check/test/build ayrılmış. Security checks gereken repo’larda required. Critical status check için trusted source değerlendirildi. Flaky checks hard gate değil. Rulesets Organization baseline var. Critical repository için ek ruleset var. Rule layering anlaşılıyor. Rollout öncesi Evaluate mode değerlendirildi. Rule Insights düzenli inceleniyor. Bypass Bypass list minimum. Admin bypass bilinçli karar. App/bot bypass gerekçeli. Copilot/AI agent bypass varsayılan değil. PR-only bypass mümkünse tercih ediliyor. Bypass activity audit ediliyor. AI Agent Agent yalnızca gerekli repository’de aktif. Agent çalışma branch’i kullanıyor. Agent-authored PR human review’dan geçiyor. AI instruction/config dosyaları korunuyor. Workflow değişikliklerinde özel review var. Agent için production bypass bulunmuyor veya açıkça gerekçelendirilmiş. Merge Required checks gerçekten geçiyor. CODEOWNER gerekiyorsa onayladı. Human approval mevcut. Yüksek merge hacminde merge queue değerlendirildi. Production deployment gate ihtiyacı değerlendirildi. InoviqLab teknik değerlendirmesi Bu bölüm InoviqLab değerlendirmesidir; GitHub’ın zorunlu policy’si değildir. Repository governance konusunda en büyük hata: “Developer’lara güveniyoruz.” veya: “AI agent zaten güvenli.” düşüncesiyle teknik kontrolleri azaltmaktır. Governance güven eksikliğinden kurulmaz. Şunun için kurulur: İnsan hata yapabilir Agent hata yapabilir CI yanlış konfigüre olabilir Token ele geçirilebilir PR sonradan değişebilir Bu yüzden sistem yalnızca niyete değil, enforcement’a dayanmalıdır. Birinci prensip: Kod yazan ile kodu kabul eden aynı yetki olmamalı İnsan veya AI fark etmez. Güçlü model: AUTHOR ↓ PR ↓ INDEPENDENT CHECKS ↓ REVIEWER ↓ MERGE olmalıdır. GitHub Copilot cloud agent’ın kendi PR’ını approve veya merge edememesi bu separation-of-duties yaklaşımının pratik örneğidir. (GitHub Docs) İkinci prensip: AI agent için yeni kurallar icat etmek yerine mevcut SDLC guardrail'lerini güçlendirin AI döneminde bazen çözüm: 50 yeni AI policy gibi düşünülüyor. Oysa mevcut güçlü kontroller: PR CI CODEOWNERS required review branch protection security scanning AI-generated code’a da uygulanabilir. GitHub’ın kurumsal Copilot governance önerisi de yeni bir paralel SDLC kurmak yerine mevcut repository governance kontrollerini agent work üzerinde enforce etmeye dayanıyor. (GitHub Docs) Üçüncü prensip: Bypass governance'ın kör noktasıdır Ruleset ekranında: PR required ✅ 2 reviews ✅ Security ✅ görmek rahatlatıcıdır. Ama: 10 actor always bypass varsa gerçek policy farklıdır.

Bu nedenle governance değerlendirmesinde ilk bakılacak alanlardan biri:

• Kim bypass edebilir?

olmalıdır. Dördüncü prensip: Kuralların çalışıp çalışmadığını ölçün Ruleset kurmak son değildir.

Şunlara bakın:

• Kaç fail?

Kaç bypass?

Hangi repo?

Hangi actor?

Hangi kural?

GitHub’ın 12 Ağustos 2026’da organization seviyesine çıkardığı Rule Insights tam olarak bu görünürlüğü sağlamayı hedefliyor. (The GitHub Blog) Governance: configuration değil, ölçülen bir süreç olmalıdır. Beşinci prensip: Agent'ın yaptığı değişiklik türüne göre review derinliği değişmeli Şu iki PR aynı riskte değildir: Agent: README typo ve: Agent: deployment workflow + IAM + database migration Bu nedenle CODEOWNERS ve path-based rules: AI agent’ı tamamen yasaklamadan risk bazlı kontrol sağlayabilir. Altıncı prensip: En iyi ruleset geliştiricilerin sürekli bypass etmek zorunda kalmadığı ruleset'tir Çok gevşek policy: risk oluşturur. Çok katı policy: bypass culture oluşturur. Dengeli governance: Risk ↓ Minimum Effective Control ile tasarlanmalıdır.

Sonuç

Repository güvenliği artık yalnızca:

• main'e push kapalı mı?

sorusuyla yönetilemez. Modern repository’de:

• insanlar,
• CI/CD uygulamaları,
• dependency bot’ları,

AI coding agent’lar aynı codebase üzerinde işlem yapabilir. Bu nedenle güçlü model: Organization Baseline ↓ Repository-specific Ruleset ↓ Pull Request ↓ Required CI ↓ Path-based Ownership ↓ Human Review ↓ Controlled Bypass ↓ Protected Branch şeklinde kurulabilir. GitHub rulesets, klasik branch protection’a göre özellikle:

• birden fazla policy’yi katmanlayabilme,
• organization genelinde uygulama,
• Evaluate mode,
• ruleset insights,

kontrollü bypass açısından daha güçlü governance olanakları sunuyor. (GitHub Docs) AI agent tarafında ise temel prensip değişmiyor: Agent'a güvenli kod yazmasını söylemek yerine, güvenilmeyen kodun kontrol edilmeden production branch’ine giremeyeceği sistemi kurun.