CommitBrief'e summary ve remote: değişikliğin brifini almak, PR'ı terminalden incelemek

İlk yazıda CommitBrief’i niye yazdığımı, ikincisinde üç 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:

$ 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ığı:

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 <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.

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=<severity> 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 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
• commitbrief.com
• Portfolyo sayfası: /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.