Pull request akışı

7. ders "iş main'e nasıl girer" sorusunu strateji düzeyinde cevapladı; bu ders girişin kendisini anlatır. Pull request (PR; GitLab'da merge request, MR) bir dal, o dal üzerinde bir tartışma ve main'in önünde bir kontrol kapısıdır. Ders, PR'ı açma disipliniyle başlar (küçük, tek amaçlı, iş kaydına bağlı), inceleyenin neye bakacağını sıralar, sonra kapının makine tarafını kurar: zorunlu durum kontrolleri, korumalı dal, CODEOWNERS ve 5. dersin senedi merge queue — "iki PR ayrı ayrı yeşil, birlikte kırmızı" sorununun çözümü. 4. dersin "force push yasağı"nın sunucu tarafı da burada ödenir. Bitişte kıdem notu: kod incelemesi bir kalite aracı olduğu kadar ekibin bilgi paylaşım aracıdır; öyle kullanılmayan inceleme, darboğaza dönüşür.

01Ne öğreneceksin

02PR nedir, nerede yaşar

Git'in kendisinde "pull request" yoktur. Kavram, Git'in doğduğu e-posta iş akışından gelir: geliştirici yamasını gönderir ve bakımcıdan "şu dalımdan çek" (pull) diye rica eder — adın kökeni budur ve 4. dersin çatal (fork) düzeninde hâlâ aynen böyledir. GitHub, GitLab ve Azure DevOps bu ricayı bir web nesnesine çevirdi: kaynak dal, hedef dal, açıklama, satır satır yorumlar, onaylar ve durum kontrolleri tek sayfada. Platform bunu sunucudaki depoya ref olarak da yazar — GitHub'da refs/pull/42/head (PR'ın dalı) ve refs/pull/42/merge (PR'ın hedef dalla birleşmiş hâli; CI genellikle bunu test eder). Bir PR'ı yerelde incelemek istersen kopyalamana gerek yoktur:

git fetch origin pull/42/head:pr-42      (GitLab: merge-requests/42/head)
git switch pr-42
gh pr checkout 42                        (GitHub CLI aynı işi tek komutla yapar)

Yaşam döngüsü her platformda aynıdır: dal push edilir → PR açılır → CI koşar → inceleme ve düzeltme turları → onay → merge → kaynak dal silinir. Her adımın bir sahibi ve bir "kapı"sı vardır; bu dersin geri kalanı adım adım o kapıları kurar. PR'ın değeri, main'e girecek her değişikliğin ikinci bir gözden ve makine kontrolünden geçmesidir: kod incelemesi, 15. hattın test ağının insan katmanıdır.

03Açma disiplini: iyi PR nasıl olur

İncelemenin kalitesi büyük ölçüde PR açılmadan önce belirlenir. Kurallar:

• Küçük ve tek amaçlı. Bir PR bir şeyi yapar: özellik, düzeltme, yeniden düzenleme — karışık değil. Pratik sınır birkaç yüz satır; ötesinde inceleyen satır satır okumayı bırakıp göz gezdirir ve onaylar, yani büyük PR daha az incelenir. Biçimlendirme değişikliği (15-10) her zaman ayrı PR'dır — 2. dersin .git-blame-ignore-revs'i bunun içindir. Büyük iş, birbirine bağımlı küçük PR'lar zinciri (stacked PR) hâlinde açılır; 6. dersin --update-refs'i bu zinciri yönetir.
• Şablon. Depoda .github/PULL_REQUEST_TEMPLATE.md (GitLab: .gitlab/merge_request_templates/, Azure DevOps: .azuredevops/) her PR açıklamasını aynı iskeletle açar: Ne değişti · Neden · Nasıl test edildi · Risk ve geri alma planı · İlgili iş kaydı · Kontrol listesi. "Neden" en önemli bölümdür; diff "ne"yi zaten gösterir.
• İş kaydı bağı. Dal adında (3. ders: fix/BAS-201-saat-dilimi) ya da açıklamada Closes #201 / AB#201: platform PR'ı iş kaydına bağlar, merge'de kaydı kapatır — 9. dersin izlenebilirlik matrisi buradan otomatik doğar.
• Taslak PR (draft). Bitmemiş işi erken görünür kılmak için: CI koşar, tasarım hakkında erken yorum alınır, ama "incele" isteği gitmez. Bitince "ready for review".
• Önce kendin incele. PR'ı açtıktan sonra diff'i inceleyen gözüyle bir kez oku: unutulan debug satırı, yanlış dosya, eksik test çoğu zaman yazarın kendi turunda yakalanır. Ekip arkadaşının zamanı, senin gözden kaçırdıklarına harcanmamalı.
• Temiz commit'ler. Ekip rebase-ff ya da merge commit kullanıyorsa dal 6. dersin interactive rebase'iyle temizlenir: "WIP", "typo", "geri al" main'e girmez. Squash kullanılıyorsa bu adım isteğe bağlıdır ama PR'ın okunmasını kolaylaştırır — inceleyen commit commit ilerleyebilir.

Şablonun kontrol listesi kısmı, ekibin DoD'sinin (10. ders) PR'a iliştirilmiş hâlidir: testler eklendi, dokümantasyon güncellendi, migration var mı, yapılandırma değişikliği duyuruldu mu, güvenlik etkisi düşünüldü mü. Liste uzadıkça okunmaz; beş-altı maddeyi geçmemeli.

04İnceleme: ne aranır, nasıl söylenir

İnceleyen, sınırlı zamanını en yüksek getirili sorulara harcar. Sıra bilinçlidir:

Son satır önemlidir: biçim tartışması inceleme zamanını yer ve gerginlik üretir; kural .editorconfig + analizör + CI'da dotnet format --verify-no-changes ile makineye verilir, insan mantığa bakar. Yorum adabı, incelemenin ekipte yaşayıp yaşamayacağını belirler:

• Önek kullan: nit: (küçük, engelleyici değil), soru:, öneri:, blok: (bu düzelmeden merge olmaz). "Conventional Comments" adıyla yerleşmiş bu düzen, yazarın neyin zorunlu olduğunu anında görmesini sağlar.
• Gerekçe ver ve mümkünse kod öner: platformların "suggestion" bloğu tek tıkla uygulanır. "Bu yanlış" değil, "son gün dahil olmalı çünkü şartname 'son gün saat 23:59'a kadar' diyor; <= öneririm".
• Koda konuş, kişiye değil: "bu metot" — "sen". Soru biçimi çoğu zaman en iyisidir: "Bu null olabilir mi?"
• Üç sonuçtan birini ver: onay, değişiklik iste (bloklar), yalnız yorum. "LGTM" (looks good to me) yazıp hiç yorum bırakmamak, PR'ı okumadığının işaretidir; en azından neyi kontrol ettiğini yaz.

Yazar tarafı. Yorum, kişiye değil koda gelir; cevap savunma değil açıklamadır: haklıysa düzelt ve "düzeltildi: abc123" yaz; katılmıyorsan gerekçeyle söyle, karar veremiyorsanız beş dakikalık konuşma yüz satır yazışmadan iyidir. "Bunu sonra düzeltirim" cevabı ancak bir iş kaydı numarasıyla geçerlidir (15-11 teknik borç kaydı). Her yoruma yanıt verilir, yanıtsız yorum "görmedim" demektir. 15-11'in suçsuz kültürü burada da geçerlidir: inceleme, hata bulmanın kutlandığı yerdir — üretimde bulunmasından ucuzdur. Yeni push, açık yorumları otomatik çözmez; yazar "düzeltildi" der, inceleyen kapatır.

05Zorunlu durum kontrolleri: kapının makine tarafı

İnsan incelemesi pahalı ve kaçırmaya açıktır; makinenin kontrol edebileceği hiçbir şey insana bırakılmaz. PR açıldığında ve her push'ta CI (18. hat) koşar, sonucunu platforma durum (status check) olarak yazar; korumalı dal bu durumların yeşil olmasını zorunlu tutar — kırmızıyken merge düğmesi kapalıdır, yönetici için de:

İki ince nokta. Birincisi, CI neyi test ediyor: dalın kendisini mi, hedef dalla birleşmiş hâlini mi? GitHub varsayılan olarak refs/pull/N/merge'i, yani birleşmiş hâli çeker; bu, "dalda yeşil, merge'de kırmızı" hatasının ilk savunmasıdır — ama yalnız PR açıldığı andaki main'e göre. Main sonradan ilerlerse sonuç bayatlar; bunun tam çözümü 07. bölümün merge queue'sudur. İkincisi, kontrol seti PR'ın hedefine göre değişebilir: main'e giden PR'da tam paket, dokümantasyon dalına giden PR'da yalnız bağlantı denetimi. Zorunlu kontrol sayısı arttıkça PR döngüsü uzar; 10 dakikayı aşan CI, geliştiriciyi PR'ı bekletmeye ve büyütmeye iter — 7. dersin "hızlı CI" ön şartı burada somutlaşır.

06Korumalı dal, onaylar, CODEOWNERS

4. dersin senedi: --force yasağı ekip kuralı olarak kırılabilir, sunucu kuralı olarak kırılamaz. Korumalı dal (GitHub: branch protection / rulesets; GitLab: protected branches + approval rules; Azure DevOps: branch policies) main'e ve sürüm dallarına şu kuralları koyar:

• Doğrudan push yok: değişiklik yalnız PR ile girer. Force push yok, dal silme yok.
• Zorunlu durum kontrolleri (05. bölüm) ve "güncel olmalı" seçeneği: PR merge'den önce hedef dalın son hâlini içermeli — yoksa yazar rebase/merge edip CI'ı yeniden bekler (merge queue bunu otomatikleştirir).
• En az N onay (tipik 1-2); yazar kendi PR'ını onaylayamaz; bayat onay düşer (dismiss stale approvals): onaydan sonra yeni push gelirse onay geçersizdir — aksi hâlde "onaylandı, sonra bir commit daha atıldı" açığı kalır. Bu seçenek kapalıysa inceleme tiyatrodur.
• Çözülmemiş konuşma varken merge yok; isteğe bağlı doğrusal geçmiş (yalnız squash/rebase) ve imzalı commit (GPG/SSH imzası; 14-04'ün PKI'sı Git'te — "bu commit gerçekten bu kişiden mi").
• Yöneticilere de uygula. İstisna, kuralın olmadığı anlamına gelir; acil durum için kural geçici olarak gevşetilir ve bu değişiklik denetim kaydına düşer.

CODEOWNERS, deponun kökünde ya da .github/ altında, yol deseni → sahip eşlemesi tutan bir dosyadır; eşleşen dosyaya dokunan PR'a o sahipler otomatik inceleyen olarak atanır ve korumalı dal "sahip onayı şart" diyebilir:

*                       @kurum/backend-ekibi
/src/Kimlik/            @kurum/guvenlik   @ayse
/src/Migrations/        @kurum/veritabani
/.github/workflows/     @kurum/platform
/docs/                  @kurum/teknik-yazim

Son eşleşen satır kazanır; desenler .gitignore sözdizimindedir (2. ders). Bunun anlamı: kimlik koduna dokunan PR güvenlik ekibi görmeden, migration veritabanı sahibi görmeden main'e giremez — 14-11'in "görev ayrılığı" kontrolü Git'e yazılmıştır ve denetçiye kanıt olarak gösterilebilir. Tuzak: sahibi tek kişi olan yol, o kişi izindeyken ekibi kilitler; sahip her zaman takım ya da en az iki kişi olmalı.

07Merge, merge queue ve sonrası

Merge düğmesinin üç seçeneği 7. derste karşılaştırıldı; ekip birini seçer ve platform ayarında diğerlerini kapatır. Burada iki ek mekanizma var. Otomatik merge (auto-merge): yazar "koşullar sağlanınca birleştir" der; onaylar ve kontroller tamamlanınca platform merge eder — kimse "yeşil oldu mu" diye sayfayı yenilemez.

Merge queue, 5. dersin senedidir. Sorun: A ve B PR'ları ayrı ayrı main'e göre test edildi, ikisi de yeşil; A merge edildi, B'nin testi artık A'sız bir main'e göre bayat — A ile B birlikte kırmızı olabilir (anlamsal çatışma: A metodu yeniden adlandırdı, B eski adla çağırıyor; satır çatışması yok). Klasik çözüm "güncel olmalı" kuralıdır: B yazarı main'i çeker, CI yeniden koşar, bu arada C merge olur, B yine bayat — yoğun depoda kimse merge edemez. Merge queue bunu sıraya alır: onaylanan PR kuyruğa girer; platform her PR'ı kuyruktaki öncekilerle birleşmiş geçici bir dalda test eder, yeşil olanları sırayla main'e alır, kırmızı olanı kuyruktan çıkarıp yazarına geri verir. Toplu (batch) modda birkaç PR birlikte test edilir, biri kırılırsa ikiye bölünür — 6. dersin bisect mantığı. Sonuç: main'e giren her commit, gerçekten giren hâliyle test edilmiştir; "sürekli entegrasyon" sözünün tam karşılığı. Bedeli: kuyruk CI süresiyle sınırlıdır — 10 dakikalık CI, saatte en fazla altı sıralı merge demektir; batch bunun için vardır.

Merge sonrası: kaynak dal silinir (platform ayarı "delete branch on merge"; yerelde git fetch --prune ve branch -d/-D — 3. ve 4. ders). İş kaydı kapanır, dağıtım tetiklenir (18. hat). Sorun çıkarsa platformun revert PR düğmesi 6. dersin revert -m 1'ini yeni bir PR olarak açar — paylaşılan dalda geçmiş yeniden yazılmaz, geri alma da incelemeden geçer.

08Kültür ve metrikler

PR akışı bir ekipte iki biçimde bozulur: darboğaz (PR'lar günlerce inceleme bekler, dallar uzar, 7. dersin tüm maliyetleri geri gelir) ve tiyatro (herkes "LGTM" yazar, hiçbir şey yakalanmaz). İkisine karşı ölçülen üç sayı:

• İlk incelemeye kadar süre. Hedef saatler, günler değil; çoğu ekip "iş günü içinde" sözü verir. İnceleme, "vakit bulunca" değil günün planlı bir parçasıdır — sabah ilk iş açık PR'lar.
• PR döngü süresi (açılıştan merge'e). DORA lead time'ının en büyük dilimi çoğu zaman kod yazmak değil, PR'da beklemektir.
• PR boyutu dağılımı. Medyan birkaç yüz satırı geçiyorsa inceleme kalitesi düşmüştür; büyük PR yüzeysel okunur.

Ve kıdem notu: kod incelemesi yalnız kalite aracı değil, ekibin bilgi paylaşım aracıdır. Bir modülü yalnız yazarı biliyorsa (bus factor 1), inceleme o bilgiyi ikinci kişiye taşıyan tek düzenli mekanizmadır; kıdemli kıdemsizin PR'ında öğretir, kıdemsiz kıdemlinin PR'ında "neden böyle" diye sorarak öğrenir — bu yüzden inceleyen ataması rastgele ya da dönüşümlü olmalı, hep aynı iki kişiye gitmemeli. Eş programlama ve mob çalışması yapan ekiplerde PR incelemesi hafifler (inceleme yazarken oldu); yine de PR kalır, çünkü kapı yalnız insan değil makinedir. AI destekli inceleme araçları (22. hat) ilk turu — bariz hatalar, eksik test, stil — üstlenebilir; iş kuralı ve tasarım kararı insan turunda kalır.

09Mini alıştırma — kapıyı kur

10Kendini sına

İyi bir PR nasıl açılır? Boyut, açıklama, iş kaydı bağı ve taslak PR neden önemlidir?

Küçük ve tek amaçlı: bir PR bir şey yapar; birkaç yüz satırı aşınca inceleyen satır satır okumayı bırakıp göz gezdirir, yani büyük PR daha az incelenir; biçimlendirme ayrı PR'dır; büyük iş bağımlı küçük PR'lar zinciri (stacked) olarak açılır. Şablon her açıklamayı aynı iskeletle açar — ne, neden, nasıl test edildi, risk ve geri alma, iş kaydı, kısa kontrol listesi (DoD'nin PR'a iliştirilmiş hâli); "neden" en önemli bölümdür çünkü diff "ne"yi gösterir. İş kaydı bağı (dal adı ya da Closes #N) PR'ı iş yönetimine bağlar, merge'de kaydı kapatır, izlenebilirlik matrisini otomatik üretir. Taslak PR bitmemiş işi erken görünür kılar: CI koşar, tasarım hakkında erken yorum alınır, inceleme isteği gitmez. Ayrıca yazar PR'ı önce kendisi inceler (debug satırı, yanlış dosya, eksik test) ve ekip rebase/merge commit kullanıyorsa commit'leri interactive rebase ile temizler.

Kod incelemesinde hangi sırayla neye bakılır? Yorum adabı ve yazarın tavrı nasıl olmalıdır; neden biçimlendirme inceleme konusu değildir?

Sıra getiriye göredir: (1) doğruluk — iş kuralı ve kenar durumlar, sınır değerler; (2) test — var mı, doğru şeyi mi sınıyor, kırmızı olabilir mi, negatif senaryo var mı; (3) tasarım — sorumluluk, bağımlılık yönü, mevcut desenle uyum; (4) güvenlik — girdi doğrulama, yetki (IDOR), sır, PII log'a düşüyor mu; (5) performans/bellek — N+1, döngüde sorgu, erken materyalizasyon; (6) okunabilirlik — isimler, boyut. Biçimlendirme inceleme konusu değildir: .editorconfig + analizör + CI'da biçim doğrulaması ile makineye verilir; insan zamanı mantığa ayrılır, biçim tartışması gerginlik üretir. Yorum adabı: önekler (nit / soru / öneri / blok) neyin zorunlu olduğunu gösterir; gerekçe ve mümkünse suggestion bloğuyla kod; koda konuş, kişiye değil; soru biçimi; üç sonuçtan biri — onay, değişiklik iste, yorum; yorumsuz "LGTM" okumadığının işaretidir. Yazar: savunma değil açıklama; haklıysa düzelt ve özetle bildir, katılmıyorsan gerekçeyle söyle, uzarsa konuş; "sonra düzeltirim" yalnız iş kaydı numarasıyla geçerli; her yoruma yanıt; suçsuz kültür — inceleme hatanın en ucuz bulunduğu yerdir.

Korumalı dal hangi kuralları koyar? "Bayat onay düşer" ve CODEOWNERS ne işe yarar? Zorunlu durum kontrolleri neleri kapsar?

Korumalı dal, main ve sürüm dallarına sunucu tarafında kural koyar: doğrudan push yok (yalnız PR), force push ve silme yok — 4. dersin force yasağının sunucu tarafı; zorunlu durum kontrolleri yeşil olmadan merge düğmesi kapalı; "güncel olmalı" seçeneği; en az N onay, yazar kendini onaylayamaz; çözülmemiş konuşma varken merge yok; isteğe bağlı doğrusal geçmiş ve imzalı commit; yöneticilere de uygulanır — istisna kuralın yokluğudur. Bayat onayın düşmesi: onaydan sonra gelen yeni push onayı geçersiz kılar; kapalıysa "onaylandı, sonra bir commit daha" açığı kalır ve inceleme tiyatroya döner. CODEOWNERS: yol deseni → sahip eşlemesi (.gitignore sözdizimi, son eşleşen kazanır); eşleşen dosyaya dokunan PR'a sahipler otomatik inceleyen atanır ve korumalı dal sahip onayını şart koşabilir — kimlik koduna güvenlik ekibi, migration'a veritabanı sahibi bakmadan main'e girilmez; görev ayrılığı kanıtı; sahip tek kişi olmamalı. Zorunlu kontroller: build + testler, biçim/analizör, diff kapsaması (bu PR'ın satırları), sır taraması, bağımlılık taraması, SAST, commit mesajı/dal adı deseni; CI genellikle PR'ın hedefle birleşmiş hâlini (refs/pull/N/merge) test eder ama sonuç main ilerledikçe bayatlar.

Merge queue hangi sorunu çözer, nasıl çalışır? Kod incelemesinin kalite dışındaki işlevi nedir ve hangi metriklerle izlenir?

Sorun: iki PR ayrı ayrı main'e göre yeşil; ilki merge olunca ikincisinin testi bayat kalır ve ikisi birlikte kırmızı olabilir — anlamsal çatışma (biri metodu yeniden adlandırdı, öteki eski adla çağırıyor; satır çatışması yok). "Güncel olmalı" kuralı yoğun depoda kimseyi merge ettirmez. Merge queue onaylanan PR'ları sıraya alır, her PR'ı kuyruktaki öncekilerle birleşmiş geçici dalda test eder, yeşilleri sırayla main'e alır, kırmızıyı kuyruktan çıkarıp yazarına verir; batch modda birkaç PR birlikte test edilir, kırılınca ikiye bölünür. Sonuç: main'e giren her commit gerçekten giren hâliyle test edilmiştir; bedeli CI süresine bağlı kuyruk hızı. Merge sonrası dal silinir, sorun çıkarsa revert PR (revert -m 1 yeni PR olarak). İncelemenin ikinci işlevi bilgi paylaşımı: bus factor 1 olan modülün bilgisini ikinci kişiye taşıyan tek düzenli mekanizma; kıdemli öğretir, kıdemsiz sorarak öğrenir; bu yüzden inceleyen ataması dönüşümlü olmalı. Metrikler: ilk incelemeye kadar süre (saatler; iş günü içinde), PR döngü süresi (lead time'ın en büyük dilimi çoğu zaman beklemedir), PR boyutu dağılımı (medyan büyüdükçe inceleme yüzeyselleşir). Bozulma biçimleri: darboğaz ve tiyatro.

11Sınav köşesi