Claude Code git hook'ları gizli anahtarları durdurabilir, formatlamayı zorlayabilir, doğru testleri çalıştırabilir ve daha hızlı incelemeler için kısa commit özetleri yazabilir.
Çoğu inceleme sıkıntısı "zor" koddan gelmez. Commit'e karışan ve önlenebilir küçük hatalardan gelir: açık bırakılmış bir debug bayrağı, gürültülü diff oluşturan biçimlendirilmemiş bir dosya, güncellenmemiş test veya yapılandırmaya kopyalanmış bir gizli anahtar. Her biri küçük olsa da bir araya geldiğinde temiz bir incelemeyi uzun bir gidip gelmeye dönüştürür.
Commit anındaki otomasyon bunu durdurmanın en kolay yeridir. Kontroller commit oluşturulmadan hemen önce çalıştığında, değişiklik hâlâ zihninizde taze iken sorunları yakalar. Bir hatayı düzeltmek saniyeler alır çünkü zaten işin bağlamındasınızdır. Buna karşılık bir PR'de iki gün sonra bulduğunuzda, araya daha fazla commit girer ve inceleyici ne olduğunu sormak zorunda kalır.
Git hook'ları pratik bir araçtır çünkü yerelde, CI beklemeden çalışır. Ama sihir değildirler. Hook'lar atlanabilir, yanlış yapılandırılabilir veya makineler arasında tutarsız olabilir; bu yüzden ekip bunları standardize etmelidir. Tek başına kalite garanti etmezler. Onları kapılar değil, korkuluklar olarak düşünün.
Hook'ların en çok yardımcı olduğu yer "inceleme vergisi"dir — sürekli tekrar eden, düşük değerli geri bildirimler. Yaygın örnekler arasında token gibi görünen hassas dizeler, formatlama ve lint gürültüsü, "doğru testleri çalıştırdın mı?" kontrolleri ve inceleyicinin amacı anlamasına yardım eden küçük bağlam özetleri vardır.
İşte Claude Code git hook'larının iyi uyduğu yer: sıkıcı doğrulama işlerini yapabilir ve commit anında biraz insan okunabilir bağlam ekleyebilir.
Beklenti belirlemek önemlidir. Yerel hook'ları hızlı ve öngörülebilir tutun ki insanlar onlardan nefret etmesin. Hızlı kontroller laptopunuzda; yavaş kontroller daha sonra olmalı. İyi bir ayrım commit anında saniyeler, CI'de dakikalar şeklindedir. Bir hook düzenli olarak o kadar uzun sürerse ki biri "skip" kullanıyorsa, depoyu korumayı bırakır.
Basit bir örnek: bir modül değiştirip birkaç fonksiyonu refactor ettiniz. Otomasyon yoksa, inceleyici 400 satır taşınmış, testlerden bahsedilmeyen bir commit görür ve temel soruları sormak zorunda kalır. Commit anı kontrolleri ile commit formatlanmış, ilgili test seti çalışmış ve commit mesajı kısa bir özet içerir. İnceleme olması gereken yerde başlar: tasarımda, temizlikte değil.
Git hook'ları basit kontroller için harikadır, ama genellikle "evet-hayır" kurallarıyla sınırlıdır: "dosya formatlı mı?" veya "linter çalıştırıldı mı?". Claude Code, sahnedeki diff'i ve birkaç ilgili dosyayı okuyarak insanların nasıl incelediğine daha yakın kararlar verebilen hafif bir yargı katmanı ekleyebilir.
Claude Code git hook'larıyla, hook gerçekte neyi değiştirdiğinize bakabilir, sadece depoda ne olduğunu değil. Bu, otomasyonu daha seçici kılar. Dokunulan modüllere, düzenlenen yapılandırma dosyalarına ve yeni çevre değişkenlerine odaklanabilir; her commit'i tam bir build gibi ele almak yerine.
"Diff'i oku ve düşün" yaklaşımının işe yaradığı pratik görevler:
Kısıtlar önemlidir çünkü yavaş bir hook atlanan bir hook olur. Hedefi küçük tutun: yaygın hataları erken yakalayacak korkuluklar ekleyin, her commite ikinci bir CI sistemi koymayın.
İyi bir kural: birkaç saniyede bitiremiyorsa muhtemelen CI veya pre-push' a aittir. Birçok ekip commit anında hızlı kontroller çalıştırır ve ağır test setlerini daha sonra bırakır.
Başarısızlık senaryolarını planlayın. Bir model çağrısı zaman aşımına uğrarsa commit'i engelleyecek misiniz yoksa daha basit bir kontrole mi döneceksiniz? Bir geri dönüş, iş akışını öngörülebilir kılar ve insanları hook'ları devre dışı bırakmaya alıştırmaz.
Bazı kurulumlar hosted model çağırır; bazıları daha izole ortamlarda çalışır. Hangi kodun geliştirici makinesinden çıkabileceğine (varsa) karar verin ve gönderdiklerinizi sınırlandırın. Staged diff ve birkaç referans dosya genellikle yeterlidir.
Hassas depolarla çalışıyorsanız, analizin nerede çalıştığını ve nelerin loglandığını açıkça belirtin. Somut bir örnek: bir commit STRIPE_SECRET=... gibi yeni bir yapılandırma değeri ekliyorsa, hook commit'i durdurup neyin riskli göründüğünü açıklayabilir ve uzak depoya ulaşmadan önce bunu bir gizli yöneticiye veya yerel env dosyasına taşımayı önerebilir.
Git hook'ları sadece insanlar onları açık tutarsa ve commitleri korkunç hale getirmezse faydalıdır. Püf nokta doğru iş için doğru hook'u seçmek ve yavaş olan her şeyi sıcak yol dışına koymaktır.
Kontrollerin genelde nerede olacağına basit bir harita:
Claude Code git hook'larını eklerken, onları hemen gelen yardımcı bir inceleyici gibi davranın, darboğaz değil. Ağ çağrısı gerektiren, tam test setleri veya uzun analizler gerektiren her şeyi pre-push veya CI'ye koyun, pre-commit'e değil.
Ne çalıştırılacağına karar vermek için pratik bir yol: kontrolleri hız ve etkiye göre sırala. Yüksek riskli sorunları (sızdırılmış anahtarlar gibi) yakalıyorsa ve saniye veya iki içinde çalışabiliyorsa pre-commit'e koyun. 30–90 saniye alan bir şeyse pre-push'a taşıyın veya yalnızca belirli dosyalar değiştiğinde çalıştırın.
Ekiplerin zorlayıcılık konusunda net bir duruşu olmalı. Tek kişilik bir repoda tercih opt-in hook'lar olabilir. Ekip reposunda, temel kurallar (gizlilik, formatlama, commit mesaj kuralları) zorlayıcı yapılır ve daha ağır kontroller yerelde tavsiye niteliğinde bırakılır; CI nihai kapı olur.
Hook çıktısı sandığınızdan daha önemlidir. Başarısız olan bir hook ne olduğunu ve ne yapmanız gerektiğini söylemeli. Mesajları kısa ve spesifik tutun. Mümkünse tam dosya ve satırı gösterin, tek bir net düzeltme komutu verin, sadece gerçek acil durumlar için nasıl atlanacağına dair açıklama koyun (ve ne zaman konulmaması gerektiğini), ve kullanıcı "verbose" istemedikçe devasa loglardan kaçının.
Örnek: bir projeyi Koder.ai'den dışa aktarıp yerelde commit etmeye başlıyorsanız, hızlı bir pre-commit hook kopyalanmış bir API token'ı anında yakalayabilir; pre-push ise dalga paylaşılmadan önce daha yavaş "sadece değişen modüller için testler" kuralını çalıştırır.
Bir gizli anahtar, başkası adına işlem yapmaya veya özel sistemlere erişmeye izin veren her şeydir. API tokenleri, OAuth client secret'lar, bulut anahtarları, veritabanı parolaları, özel webhook URL'leri, imzalama anahtarları ve hatta geçici test kimlikleri bile buna dahildir. Tek bir kazara commit bir fork'ta, CI log'unda veya yapıştırılmış bir diff'te kalabilir ve sonra artık geçici olmaz.
En kolay kazanım, tam olarak commit etmeyi düşündüğünüzü taramaktır. Bir hook staged değişiklikleri (index) kontrol etmeli, tüm repoyu değil. Bu hem hızlı tutar hem de dokunmadığınız eski dosyalar yüzünden gürültü yaratmaz. Ayrıca geri bildirim adildir: "bu commit bir sorun içeriyor" demek, "deponuzun geçmişinde bir sorun olmuş" demekten daha doğrudur.
Erken işaretlenecek yaygın şeyler: yüksek entropili tokenler (uzun rastgele görünen diziler), bilinen anahtar formatları (AWS anahtarları, GitHub tokenleri, JWT'ler), password=... veya api_key: ... gibi yapılandırma desenleri, kimlik bilgileri gömülü özel URL'ler ve .env dosyaları veya üretilmiş üretim konfigürasyonlarının kopyaları.
Yanlış pozitifler özellikle test verileri, hash'ler veya örnek dokümanlarda olur. Bu yüzden dar bir allowlist oluşturun ki insanlar tüm kontrolleri devre dışı bırakmak zorunda kalmasın. Allowlist dar tutulmalı: fixture'lar için kesin dosya yolları veya detektörün tanıdığı "dummy" ya da "example" gibi açık işaretleyiciler.
Bir gizli bulunduğunda commit'i durdurun ve insanlara ne yapacaklarını söyleyen bir mesaj verin. Claude Code git hook'ları bunu diff'e dayalı kısa bir açıklama üreterek daha dostane yapabilir, ama kilit nokta net, güvenli sonraki adımlardır:
ERROR: Possible secret detected in staged file: config/app.yaml (line 12)
Reason: looks like an API token
Next steps:
1) Remove it from the change or move it to env vars
2) Rotate the token (assume it is compromised)
3) Re-stage and retry commit
If this is a false positive, add a narrow allowlist rule in .secrets-allowlist
Somut örnek: biri backend konfigürasyonunu güncelliyor ve geliştirme için TEMP_API_KEY ekliyor. Hook commit'i durdurur, bunu bir çevre değişkenine taşımayı önerir ve gerçekse token'ın döndürülmesini hatırlatır. Bu küçük bir kesinti büyük bir temizliği önler.
Formatlama mücadeleleri inceleyicinin zamanını boşa harcar, ama yavaş hook'lar da hook'ların devre dışı bırakılmasının ana nedenidir. Tatlı nokta basit kurallar, her dil için bir araç ve sadece commit edilmeye çalışılan dosyalar üzerinde çalışmaktır.
Her dil için tek bir formatter seçin ve onu kaynağın gerçeği yapın. İki formatter'ın veya formatter ile kodu yeniden yazan bir linter'ın çelişmesi gürültülü diff'ler ve bitmeyen döngüler yaratır. Sıkıcı tutun: bir JS/TS formatter, bir Go formatter, bir Dart formatter. Herkesin aynı versiyonları kullandığından emin olun ki hook çıktısı makineler arasında stabil olsun.
En büyük hız kazanımı sadece staged dosyaları formatlamaktır. Her committe tüm repoyu formatlamak pre-commit hakkında en çok şikayet edilen şeydir. Sadece staged yaklaşımı diff'i odaklı tutar, tam da inceleyicilerin istediği şeydir.
Hızlı tutan pratik seçimler:
Otomatik düzeltme vs hata verme ekip tercihi olsa da karışık yaklaşım iyi çalışır. Mekanik düzenlemeler için otomatik düzeltme döngüyü atlar. Hata vermek, insanların konuyu görüp karar vermesini sağlar. Hata veriyorsanız herkesin 10 saniyede uygulayabileceği tek bir talimat yazın.
Çapraz platform gürültüsünü önlemek için küçük şeyleri standardize edin: satır sonları ve satır sonu boşlukları en sık sorun çıkaranlardır. Basit bir politika:
Claude Code git hook'ları burada yapıştırıcı görevi görür: hangi staged dosyaya hangi formatter gerektiğini tespit etmek, doğru sırayla çalıştırmak ve hataları sade bir dille açıklamak. Örneğin biri Go dosyası ve bir TS dosyası stage'lediyse, hook her biri için doğru aracı çalıştırıp sonuçları yeniden stage'leyebilir ve sonra "2 dosya yeniden formatlandı, davranış değişikliği yok" gibi kısa bir not verebilir. İnceleyiciler daha temiz difflar görür; geliştiriciler sık commit atmaktan dolayı cezalandırılmış hissetmezler.
Basit bir kural commitleri zahmetsizce daha güvenli yapar: sadece sahnelenen şeye uyan testleri çalıştır. Hook staged diff'e (çalışma ağacı değil) baktığında yarım kalmış dosyalardan kaynaklanan yanlış alarmlardan kaçınır.
Önce hangi alanların etkilendiğini tespit edin. Çoğu repo zaten doğal bir yapıya sahiptir: paketler, servisler, uygulamalar veya modüller. Bir hook git diff --cached --name-only okuyup bu yolları küçük bir test komut setine eşleyebilir.
Anlaşılır kalan birkaç eşleme kuralı:
web/ veya frontend/ -> npm test (veya sahip olduğunuz en küçük hedef komut)api/ veya server/ -> backend birim testleri (varsayılan olarak entegrasyonu atla)mobile/ -> hızlı widget/unit testleri, tam cihaz dizilerini değildb/ veya migrations/ -> migration lint + küçük şema kontrolüshared/ -> shared paket testleri ve hızlı tüketicilerClaude Code git hook'larıyla bir adım daha ileri gidebilirsiniz: staged dosya isimlerine bakıp minimal test setini önerebilir, sonra hook bu komutları çalıştırır. Yine de son karar kural tabanlı olmalı ki ekip ne olacağını öngörebilsin.
İşi commit ve push arasında bölün. Commitler hızlı kalmalı ki insanlar hook'ları atlamasın. Pratik bir desen:
Flaky ve yavaş testler için açık bir politika yoksa hook gürültü olur. Ekip olarak neyin commit'i engellediğine vs karar verin. İşe yarayan yaklaşım: net başarısızlıklarda blokla (formatlama, genelde stabil birim testleri), bilinen flaky testlerde uyarı ver, yavaş suite'leri push/CI'ye taşı. Bir test flaky ise bunu bir bug olarak görün: takip edin, düzeltin ve stabil olunca uyarı modunu kaldırın.
İyi bir diff her zaman kolay incelenmez. Kısa bir commit-öncesi özeti, değişiklik birden fazla dosyayı etkilediğinde veya refactor içerdiğinde 10 dakikalık bir okumayı 2 dakikaya indirebilir.
Fikir basit: git commit çalıştırdığınızda hook'ınız Claude Code'a staged diff'i okumasını ve inceleyicilerin her zaman sorduğu soruları yanıtlayan 3–6 satırlık bir not üretmesini ister: ne değişti, neden değişti, ne kadar riskli, ve nasıl test edildi.
Çıktıyı sıkı ve tutarlı tutun ki inceleyiciler ona güvenmeyi öğrensin:
Bunu doğrudan commit mesajına ekleyebilirsiniz (ör. kısa bir footer olarak) veya ekip PR açıklamasına kopyalanacak bir dosyaya kaydedebilirsiniz. Commit mesajı bağlamın değişiklikle birlikte gitmesini sağlar; ayrı dosya ise ekip temiz, konvansiyonel commit başlıklarını tercih ediyorsa daha iyidir.
Bir özet aracı bir inceleyiciden daha katı olmalı. Herhangi bir diff içeriğini modele göndermeden önce API anahtarları, özel anahtarlar, tokenler, .env değerleri ve kimlik bilgileri desenlerini filtreleyin. Repository HTTP trafiği yakaladıysa başlıklar ve çerezleri de filtreleyin. Hook hassas desenler algıladığında, satırları sansürleyebilir veya "credentials-related changes redacted" gibi genel bir özet ile geri dönebilir.
Örnek: bir faturalama endpoint'ini güncelliyorsunuz ve üç dosyaya dokundunuz. Staged diff rename'ler nedeniyle gürültülü olsa bile özet şöyle der: “Çift faturalamayı önlemek için charge creation'da idempotency key handling eklendi. Neden: retry'ler çift faturaya sebep oluyordu. Risk: orta (ödeme yolu). Test: billing servis için birim testleri, manuel istek tekrarları.” İnceleyicinin ihtiyacı olan tam olarak budur; her satırı okumadan önce bağlam sağlar.
Küçük bir bug'ı düzeltip aynı commit içinde bir konfigürasyon da değiştiriyorsunuz. Bug billing/tax.go içinde tek satırlık, config değişikliği config/staging.yaml içinde yeni bir endpoint'e işaret ediyor.
git commit -am "Fix tax rounding" çalıştırıyorsunuz. Claude Code git hook'ları hızlı bir dizi kontrolü, öngörülebilir bir sırada yapıyor.
İlk önce gizli tarama sadece neyin değiştiğine bakıyor, tüm repoya değil. Staging config'in gerçekte bir API anahtarı içeriyor gibi göründüğünü işaretliyor.
ERROR: Possible secret detected in config/staging.yaml:12
Pattern: api_key=sk_live_...
Fix: remove the key and use an env var reference (e.g., API_KEY)
Override: set ALLOW_SECRETS=1 (not recommended)
Değeri bir ortam değişkeni referansıyla değiştirip tekrar commitliyorsunuz.
Sonra formatlama sadece gereken yerlerde çalışıyor. Go dosyanız formatlı değilse, "billing/tax.go üzerinde gofmt çalıştır" gibi kısa bir ipucu ile başarısız olur. Formatter'ı çalıştırıp hook'un saniyeler içinde geçmesini sağlarsınız.
Ardından test kapısı hedeflenmiş bir set çalıştırır. billing/ dokunduğunuz için sadece billing birim testleri çalışır (tam suite değil). Bir test başarısız olursa, hook yerel olarak çoğaltmak için tam komutu gösterir. Yuvarlama kenar vakasını düzeltip aynı testleri yeniden çalıştırırsınız.
Son olarak hook diff'ten bir inceleyici özeti üretir. Kısa ve spesifik olur, örneğin:
İnceleyicinin gördüğü şey zaten temiz bir commit: sızdırılmış gizli anahtar yok, tutarlı formatlama ve değişikliğe uygun testler. Ayrıca hazır bir özetleri var; böylece mantığa odaklanabilirler, niyeti aramak yerine.
Hook'ları can sıkıcı yapan en hızlı yol onları acı verici yapmaktır. Bir hook akışı bölecek kadar uzun sürerse, insanlar --no-verify ile atlar veya hook'u siler. Ağır işleri pre-committen uzak tutun ve talep üzerine veya CI'de çalıştırın.
Pratik kural: pre-commit bir yazım denetimi gibi hissettirmeli, bir test paketi gibi değil. Claude Code git hook'larından daha akıllı kontroller istiyorsanız, onları ne çalıştırılacağına karar vermek için kullanın, her şeyi çalıştırmak için değil.
Hook'ları varsayılan olarak hızlı ve gerektiğinde katı yapın. Örneğin, her committe hızlı format + gizli tarama çalıştırın, ancak testleri sadece etkilenen modüller için çalıştırın.
Çalışan bir hız bütçi:
pre-commit: toplam 1–5 saniyecommit-msg: 1 saniyenin altındapre-push veya CIAI önerilerde iyidir, politika uygulamada değil. Bir AI'ya "diff'i incele" diye kuralsız istekte bulunursanız her seferinde farklı sonuçlar alırsınız. Hook'un ne yapması gerektiğini (ve ne yapmaması gerektiğini) tanımlayın. Örneğin: inceleyici özeti üretebilir, ama formatter zaten deterministik bir değişiklik üretmedikçe kodu yeniden yazmamalıdır.
Birçok hook yanlışlıkla çalışma ağacınızı tarar ve siz stage'lemediğiniz değişiklikler olduğu için commit'i başarısız kılar. Bu haksız hissettirir.
Her zaman staged içeriği girdi olarak kullanın. İyi bir test: bir dosyayı düzenleyin, sadece yarısını stage'leyin ve hook'un sadece staged olanı rapor ettiğinden emin olun.
Her committe sürekli uyarı gelirse, uyarılar gürültü olur. Desenleri ayarlayın, fixture'lar için allowlist ekleyin ve "belki" bulgularını uyarıya düşürün.
Somut örnek: gizli tarayıcınız fixtures/ içindeki test anahtarlarını işaretliyorsa, o klasörü yoksayacak bir kural ekleyin; ama app konfigürasyon dosyalarındaki gerçek anahtarları engellemeye devam edin.
Claude Code git hook'larının yardımcı olması ama ekibinizi rahatsız etmemesi için hedef basit: gerçek problemleri erken yakalayın, her şey normalken sessiz kalın ve commit döngüsünü hızlı tutun.
Çoğu repo için işe yarayan pratik kontrol listesi:
Küçük ama işe yarayan bir detay: inceleyici özetinin her seferinde aynı görünmesini sağlayın. Basit bir şablon yeterlidir ve inceleyicilerin hızlıca taramayı öğrenmesini sağlar.
Review summary:
- What changed: <1-2 bullets>
- Risky areas: <files/modules>
- Tests run: <command or “not run + why”>
Benimseyimi kolaylaştıracak sonraki adımlar:
Eğer sohbet-öncelikli şekilde araç inşa etmeyi seviyorsanız, Koder.ai (koder.ai) hook'larınız çevresinde küçük yardımcı betikler üretmek ve kaydetmeden önce anlık görüntülerle güvenle yinelemek için kullanışlı olabilir.
Tekrarlayan ve inceleyici zamanını boşa harcayan şeylerle başlayın:
Her zaman yavaş olanları (full test suite, derin statik analiz) pre-push veya CI'ye bırakın.
İyi bir varsayılan şudur:
pre-commit: staged değişikliklere bakan hızlı kontroller (gizlilik, formatlama, hızlı lint, seçici birim testleri)commit-msg: commit mesaj kuralları (uzunluk, format, ticket ID)pre-push: daha yavaş ama yerel olarak yakalanması faydalı kontroller (daha geniş testler, build)Bir kontrol düzenli olarak birkaç saniyeden fazla sürüyorsa onu daha sonra çalıştırın.
Commit zamanlı hook'ları birincil zorunluluk değil, koruyucu sınırlar olarak düşünün.
Pratik politika: hook'lar geliştiricilere yardımcı olur; main branch'i CI korur.
Staged diff'i (index) tarayın, tüm depoyu değil.
Tüm depo taraması gerekiyorsa bunu zamanlanmış görev olarak veya CI'de çalıştırın.
Yüksek güvenliğe sahip eşleşmelerde (gerçek anahtar formatları, özel anahtar blokları, yapılandırmada belirgin password= değerleri) engelleyin. Belirsiz durumlarda uyarı verin.
Ayrıca bilinen güvenli durumlar için dar bir allowlist ekleyin, örneğin:
DUMMY_KEY)Sürekli yanlış alarmlar varsa insanlar hook'u devre dışı bırakır; bu yüzden hassasiyeti ayarlayın.
Sadece staged dosyaları formatlayın ve her dil için tek bir formatter seçin.
Pratik varsayılanlar:
Böylece difflar temiz kalır ve her commit uzun bir yeniden yazma sürecine dönüşmez.
Değişen yolları küçük bir set hızlı test komutuna eşleyin.
Örnek yaklaşım:
git diff --cached --name-only ile değişen alanları tespit edinpre-push veya CI'ye bırakınBu, commitleri hızlı tutarken en yaygın kırılmaları erken yakalar.
Kısa ve tutarlı tutun (3–6 satır). Basit bir şablon:
Bunu commit mesajına ekleyebilir veya PR açıklamasına yapıştırmak üzere ayrı bir metin olarak kaydedebilirsiniz.
Model'e herhangi bir diff içeriği göndermeden önce metinleri sansürleyin ve temkinli olun.
.env değerleri, özel anahtar blokları, çerezler veya kimlik doğrulama başlıkları gibi desenleri çıkarınÖzellikle özel depolarda varsayılan olarak “daha az paylaş” prensibini uygulayın.
Hook'ları öngörülebilir ve hızlı yapın:
pre-commit için 1–5 saniye)--no-verify kullanımını izleyin ve nadiren görünüyor olsunHook yavaş veya tutarsız hissediyorsa geliştiriciler bypass'e yönelecektir.