GitHub temelleri — repo, branch, PR, koruma

GH-600’ün altıncı domain’i baştan diyor: GitHub kontrol düzlemidir. Yani agent’ı çalıştıran kim olursa olsun, izlerinin kaldığı, kararların geçtiği, guardrail’lerin uygulandığı yer GitHub’dır. Bu dersin amacı: agent perspektifinden GitHub’ın temel primitive’lerini hızlıca tanımak.

Repo — agent’ın çalışma alanı

Bir repository (repo), agent’ın scope’u olur. Sınavda Domain 2.3 “Configure an agent’s scope to a specific repository” bullet’ı tam buradan gelir. Agent’a verdiğin yazma izni repo dışına çıkmaz.

Branch — paralel çalışma kanalı

Branch, repo’nun bir kopyasıdır — main’i bozmadan değişiklik yapmana izin verir. Agent perspektifinden:

• Agent kendi branch’ini açar (Domain 2.3 “create branches”)
• İnsana zarar vermeden deneyebilir
• Hazır olunca PR açar

Pull Request (PR) — insan kapısı

PR = “şu branch’ten main’e merge etmek istiyorum, gözden geçirir misin?” isteği. Agent’lar için PR şu açıdan kritik:

1. Inspectable artifact (Domain 1.3) — agent’ın ne yaptığını insan görür
2. Required review kapısı — onay olmadan merge olmaz (Domain 6)
3. Audit trail — kim ne zaman ne onayladı, sonsuza kadar kalır

Branch protection rules — guardrail’in çekirdeği

Settings → Branches → Branch protection rules’da kurulur. GH-600’de sıkça karşına çıkacak ayarlar:

Ayar	Ne yapar	Domain
Require a pull request before merging	Direct push’u engeller	6
Require approvals (N reviewers)	Plan onaylanmadan merge yok	1, 6
Require status checks to pass	Test/lint yeşil olmadan merge yok	4
Require conversation resolution	Yorumlar çözülmeden merge yok	6
Require signed commits	İmzasız commit reddedilir	6
Restrict who can push	Sadece izinli kişi/bot push’lar	2, 6

Agent çıktısı için tipik konfig: PR zorunlu + en az 1 approval + status check yeşil.

Environment protection rules — production kapısı

Branch protection PR’a koyduğun kapı. Ama prod deploy farklı — environment-bound aksiyondur. Sınav burada iki kavramı ayırt etmeni ister:

Mekanizma	Ne için	Konum
Branch protection	Merge gate (kod main’e gidiyor mu?)	Settings → Branches
Environment protection	Deploy gate (kod prod’a deploy oluyor mu?)	Settings → Environments → [env] → Protection rules

Environment protection rules:

• Required reviewers (max 6 kişi)
• Wait timer (deploy başlamadan önce sabit bekleme — “soğuma” süresi)
• Deployment branches (sadece belli branch’lerden deploy edilebilir)

Token modeli — agent’ın kimliği

Agent GitHub’a istek atarken bir token ile kimlik gösterir. İki ana tip:

GITHUB_TOKEN (Actions içinde otomatik üretilir)

• Sadece o workflow run süresince geçerli
• Default izinleri workflow YAML’inde scope’lanabilir:

permissions:
  contents: read       # repo dosyalarını okuyabilir
  pull-requests: write # PR açıp yorum yazabilir
  issues: write        # issue açabilir
  # diğer her şey reddedilir

Fine-grained Personal Access Token (PAT)

• Bir kullanıcı/bot kimliği için manuel oluşturulur
• Repo ve scope bazında izin verilir (geniş “classic” PAT’in tersi)
• Süre dolar (max 1 yıl)
• Organization onayı gerekebilir

Audit log — system of record

GitHub’ın Organization Settings → Audit log’u, her aksiyonun kalıcı izini tutar. Agent perspektifinden bu kritik:

• Agent bir 6 ay önce branch silmiş — kim, ne zaman, hangi token? → audit log
• PR onayını kim verdi, kim merge etti? → audit log + PR history
• Webhook hangi adrese yollandı? → audit log

Domain 2.4 “traceability and accountability” tam buradan gelir.

Pratik denemen için

Bir test repo’sunda şunları kurmayı dene (1 saat — sıfır deneyim için):

1. Yeni repo oluştur: gh600-prep-sandbox
2. main branch’ine branch protection rule ekle: PR zorunlu + 1 reviewer
3. Settings → Environments → yeni env: production — required reviewer (kendin) ekle
4. Bir basit Actions workflow yaz: .github/workflows/hello.yml — on: push, permissions: contents: read, pull-requests: write, sadece “hello” diyen bir job
5. Bir feature branch’ten PR aç — koruma kurallarının uygulandığını gör

Bu küçük lab Modül 3 (Domain 2 — Tool & MCP) lab’ları için altyapı kurar.

Sırada ne var?

Bir sonraki derste GitHub Actions workflow anatomisi — trigger event’leri, job’lar, step’ler, runner’lar — agent’ın çalışacağı yürütme ortamını inceleyeceğiz.