# CommitBrief'e summary ve remote: değişikliğin brifini almak, PR'ı terminalden incelemek > İki yeni komut: summary değişikliğin brifini çıkarıyor, remote pr ise PR'ı terminalden inceleyip yorumu insandan önce bırakıyor. - Yayın: 2026-06-13 - Kategori: Günlük - Etiketler: Araçlar, Git, Go - Okuma süresi: 5 dk okuma - Kaynak: https://www.muhammetsafak.com.tr/blog/commitbrief-summary-ve-remote/ - Dil: tr-TR - Yazar: Muhammet Şafak --- [İlk yazıda](/blog/kendi-diffimi-bir-tool-a-soruyorum-commitbrief/) CommitBrief'i niye yazdığımı, [ikincisinde](/blog/ai-ile-self-review-neyi-hizlandiriyor-nerede-yetmiyor/) üç ayın sonunda neyi hızlandırıp nerede yetmediğini anlatmıştım. İkisinin de birimi aynıydı: **kendi diff'im**, henüz kimse görmeden. Soru hep "bu değişiklik bir soruna yol açıyor mu" idi. Son haftalarda araca eklediğim iki komut bu birimi genişletiyor. Biri sorunun *yönünü* değiştiriyor — "soruna yol açıyor mu" değil, "ne değişti ve neden": `commitbrief summary`. Diğeri ise aynı incelemeyi benim terminalimden çıkarıp takımın PR akışına taşıyor: `commitbrief remote pr`. Bu yazı bu iki komutu, niye eklediğimi ve ikisini de aynı çizgide tutan ilkeyi anlatıyor: **bu araç insan reviewer'ın yerini almıyor; önünden gidip bariz olanı topluyor.** ## summary — diff değil, değişikliğin hikâyesi Bir review değişikliği *eleştirir*. Bir summary değişikliği *anlatır*. İkisi farklı işler. `commitbrief summary`, bir değişiklik kümesini sade bir dille özetler: ne değiştiğini ve — commit mesajları belli ediyorsa — *neden* değiştiğini, dosya dosya değil **mantıksal alanlara göre** gruplayarak. Tamamen salt-okunur; severity üretmez, JSON üretmez, CI'da kapı kuracak bir bulgu üretmez. Sağlayıcının döndürdüğü düz metni olduğu gibi basar. Asıl yeni olan şey şu: kapsam bir aralık olduğunda, summary o aralıktaki **commit mesajlarını da okuyor** (`git log`, salt-okunur). Yani artık değişikliğin sadece son hâline değil, *geçmişine* de bakıyor. Her satırı, o alandan sorumlu kısa commit hash'iyle ilişkilendiriyor: ```text $ commitbrief summary main...develop --lang tr Fatura Servisi: Ücret hesabındaki yuvarlama hatası giderildi. (a1b2c3d) Auth: Token yenileme akışı eklendi. (d4e5f6a) DB: invoices tablosuna index eklendi. (f7a8b9c) ``` Parantez içindeki etiket bir branch adı değil, **commit hash'i** — çünkü squash ya da rebase ile birleşmiş bir geçmiş branch adını korumaz, hash'i korur. Staged/unstaged değişikliklerin henüz commit'i olmadığı için onlar atıfsız çıkar. Kapsam, review'la birebir aynı yüzeyi kullanıyor: argümansız çağırınca staged diff, `--unstaged` ile çalışma ağacı, ya da `diff` komutundaki gibi serbest bir `git diff` aralığı: ```bash commitbrief summary # staged commitbrief summary HEAD~3 HEAD # son üç commit commitbrief summary main...develop # PR tarzı aralık commitbrief summary HEAD~3 HEAD -o NOTES.md # release notu olarak dosyaya ``` `--lang tr` özeti Türkçe verir; `-o`/`--output` dosyaya yazar. Pre-send guard, secret tarama, maliyet preflight ve cache — hepsi review'daki gibi devrede. Prose ürettiği için bulgu odaklı flag'leri (`--json`, `--markdown`, `--suggest-commit`, `--fail-on`) sessizce yutmaz, açık bir mesajla reddeder. Ve git'e **asla** yazmaz. İki yerde işime yarıyor: - **Bireysel.** Bir hafta önce bıraktığım bir branch'e geri döndüğümde, diff'i baştan okumak yerine `commitbrief summary main...feature/x` ile beş satırlık bir hatırlatma alıyorum. Kendi geçmişime mesafe almak da self-review körlüğünün bir başka yüzü. - **Ekip içi.** Bir takım arkadaşının branch'ini inceleyeceğim zaman, satır satır diff'e girmeden önce *neyin nerede değiştiğinin* haritasını çıkarıyorum. Review'a kör girmiyorum; nereye bakacağımı bilerek giriyorum. Bir de yan fayda: `HEAD~3 HEAD -o NOTES.md` ile bir sürümün release notunu, commit mesajlarına dayanarak, birkaç saniyede taslak hâline getiriyorum. ## remote pr — ikinci göz, takımın PR akışında `commitbrief remote pr ` bir GitHub pull request'ini inceler ve sonucu GitHub'a geri yazar: her bulgu satır içi (inline) bir review yorumu olur, review da bir verdict ile gönderilir. Kendi HTTPS çağrısını yapmaz; yereldeki `gh` CLI'ını sürer — yani `gh`'ın auth'u, host çözümü, fork yönetimi olduğu gibi yeniden kullanılır. Önemli ayrım: bu **kullanıcının sürdüğü bir araç**, kuruluma asılı kalan bir bot değil. ```bash commitbrief remote pr 42 # mevcut repodaki PR #42 commitbrief remote pr CommitBrief/web#10 # başka repo commitbrief remote pr 42 --no-post # GitHub'a yazmadan, yerelde ``` Burada en çok üstünde durduğum tasarım kararı şu: **varsayılan verdict asla `request-changes` değil.** Bulgu yoksa `approve`, info dışında bulgu varsa `comment` — ama değişiklik isteyip PR'ı bloklamak, ancak `--request-changes-on=` ile *bilinçli olarak* açtığınızda olur. Yani araç kutudan çıktığı hâliyle bir bekçi gibi davranmıyor; satır içi yorumları bırakıp çekiliyor. Bu kasıtlı. Araç PR'a önce giriyor, gözle kolay kaçan bariz şeyleri ilgili satırın altına yorum olarak koyuyor — sonra insan reviewer geliyor. İnsanın dikkatini "kolay bulgular" yerine "zor bulgular"a odaklamak istiyorum; onun yerine karar vermesini değil. Birkaç inceliği var: - **Yorumlar doğru tarafa düşer.** Eklenen ve bağlam satırları için `RIGHT` (yeni dosya), silinen satırlar için `LEFT` (eski dosya). Silinmiş bir koda dair bulgu, silinen satırın üstüne oturur, reddedilmez. - **Diff'in dışına düşen bulgu kaybolmaz.** Satırı diff'te yoksa ya da GitHub POST'u reddederse, o bulgu review özetine "belirli bir satıra iliştirilemeyen bulgular" başlığı altında eklenir. - **`--no-post` yerel triyaj içindir.** PR'ın diff'ini salt inceleme kaynağı olarak kullanır, GitHub'a hiçbir şey yazmaz; çıktıyı tıpkı yerel review gibi terminale basar. Burada `--cli` ile API key'siz sağlayıcı, `--fail-on` ile exit-code kapısı, hatta kendi PR'ınızı inceleme bile serbesttir. - **Gönderilen metin İngilizcedir.** PR'ları karışık dilli ekipler okur; sadece yereldeki ilerleme/hata satırları TR/EN yerelleşir. - **Yarış güvenli.** Review sürerken PR'ın başı kayarsa bir kez yeniden dener; tekrar kayarsa review göndermeden durur. Posting modunda yalnızca API sağlayıcılar çalışır — `claude-cli`/`gemini-cli` gibi CLI sağlayıcıları yapısal bulgu üretmediği için reddedilir (`--no-post` altında bu kısıt kalkar). ## "Yerini almak" değil, "önünden gitmek" İki komut da bir yıl önce yazdığım cümlenin etrafında dönüyor: *üretim ucuzladıysa, üretileni denetlemek pahalı kalmamalı.* [Daha önce de anlattığım gibi](/blog/yapay-zeka-caginda-kod-yazmanin-degisen-el-becerisi/) bu araçların değer ürettiği yer "AI yazsın" değil; yazılana muhakeme uygulamanın maliyetini düşürmek. - **summary** anlamanın maliyetini düşürüyor. Bir değişikliği — kendiminkini ya da başkasının — kavramak için harcanan ilk on dakikayı beş satıra indiriyor. - **remote pr** ilk geçişin maliyetini düşürüyor. Bariz olanı insan reviewer'a ulaşmadan toplayıp, pahalı olan insan dikkatini gerçekten pahalı sorulara saklıyor. İkisi de aynı şeyi *yapmıyor*: yargıyı yerine koymuyor. Verdict'i varsayılan olarak yumuşak tuttum, summary'yi bilerek yargısız bıraktım. Çünkü bu araç bir reviewer değil; reviewer'ın önünü temizleyen bir katman. ## Sınırlar — yine dürüst liste - **summary anlatır, yargılamaz.** Intent'i ya da mimariyi sorgulamaz; "doğru özelliği mi yapıyorsun" diyemez. Squash/rebase ile dümdüz olmuş bir geçmişte commit atıfı kabalaşır — temiz iki uçlu bir aralık dışında atıf zaten verilmez. - **remote pr posting modunda API'ya bağımlı.** Aboneliğinizi yeniden kullanan CLI sağlayıcıları ancak `--no-post` altında çalışır. - **Hâlâ aynı çekirdek sınır.** CommitBrief lint'in yerine değil, **lint + test'in üstüne, insan review'un altına** bir katman. summary ve remote bu katmanı genişletiyor; sınırını kaldırmıyor. İlk iki yazının çıkarımı değişmedi, sadece yüzeyi büyüdü: AI'ın değer ürettiği nokta yargıyı kalibre etmek; yargıyı yerine koymak değil. summary kalibrasyonu kişiselden geçmişe, remote ise solodan ekibe taşıyor — kararı hâlâ insan veriyor. ## Denemek için - [github.com/CommitBrief/commitbrief](https://github.com/CommitBrief/commitbrief) - [commitbrief.com](https://commitbrief.com) - Portfolyo sayfası: [/portfolyo/commitbrief](/portfolyo/commitbrief/) `COMMITBRIEF.md`'inizi hâlâ merak ediyorum — başka projelerin "iyi kod"u nasıl tanımladığını görmek bu işin en öğretici tarafı. summary'yi bir branch'inize, `remote pr --no-post`'u bir PR'ınıza deneyip ne çıktığını yazarsanız, sevinirim.