# Git Hooks

Adres: https://softwaredictionary.org/tr/terimler/git-hooks
Kategori: Sürüm Kontrolü
Son güncelleme: 2026-09-30
Türkçe karşılığı: git kancaları
Okunuşu: git huks

Kısaca: Git hook'ları, commit ya da push öncesi gibi anlarda Git'in otomatik çalıştırdığı; kodu denetleyen, kural uygulayan ve işleri otomatikleştiren betiklerdir.

## Git hook'ları nelerdir?

Git hook'ları, bir depoda belirli olaylar gerçekleştiğinde Git'in otomatik olarak çalıştırdığı betiklerdir. Örneğin bir `pre-commit` hook'u commit oluşturulmadan hemen önce, bir `pre-push` hook'u ise değişiklikler uzak depoya gönderilmeden önce çalışır. Sorunların başkalarına ulaşmadan yakalanması için genellikle linter'ları, biçimlendiricileri ya da hızlı testleri çalıştırmak amacıyla kullanılırlar.

Hook'lar her deponun `.git/hooks` klasöründe bulunur ve bir hook, `pre-commit` veya `commit-msg` gibi olayın adını taşıyan çalıştırılabilir bir dosyadır. `pre-commit` gibi bir hook sıfırdan farklı bir durum koduyla çıkarsa Git işlemi durdurur; böylece başarısız bir denetim kötü bir commit'i engelleyebilir. `.git` klasörü izlenen proje dosyalarının parçası olmadığı için hook'lar biri depoyu klonladığında paylaşılmaz; ekipler bunları normal bir klasöre commit eder ve Git'i `core.hooksPath` ile oraya yönlendirir ya da bir hook yöneticisi aracı kullanır.

Hook'ları, bir pilotun kalkıştan önce yürüttüğü kontrol listesi gibi düşünün: uçuş ancak her madde geçildikten sonra devam eder. İstemci tarafı hook'lar geliştiricinin makinesinde çalışır; `pre-receive` gibi sunucu tarafı hook'lar ise Git sunucusunda çalışır ve bir bilet numarası içermeyen commit mesajları gibi ekip kurallarını çiğneyen push'ları reddedebilir.

Git hook'ları bazen CI/CD hatlarıyla karıştırılır. Yerel hook'lar hızlı geri bildirim verir, ancak her geliştirici bunları `git commit --no-verify` ile atlayabilir; bu yüzden kaliteyi tek başlarına garanti edemezler ve ekipler hız için hook'ları, son kapı olarak da CI'ı kullanır. Git hook'ları ayrıca, bir barındırma platformunun bir depoda bir şey olduğunda başka hizmetlere gönderdiği HTTP istekleri olan webhook'lardan da farklıdır.

## Önemli noktalar

- Hook'lar, commit, merge veya push gibi olaylarda Git'in otomatik çalıştırdığı betiklerdir.
- `pre-commit` gibi bir hook'un sıfırdan farklı çıkış kodu, işlemi iptal eder.
- `.git/hooks` içindeki hook'lar klonlamayla paylaşılmaz; bu yüzden ekipler `core.hooksPath` ya da bir hook yöneticisi kullanır.
- İstemci tarafı hook'lar `--no-verify` ile atlanabilir; bu yüzden son denetim CI'da kalır.
- `pre-receive` gibi sunucu tarafı hook'lar herkes için kuralları uygulayabilir.

## Örnek: Linter ve testleri çalıştıran bir pre-commit hook'u

```bash
#!/bin/sh
# .githooks/pre-commit: runs automatically before every commit

echo "Running linter and tests..."
npm run lint || exit 1   # a non-zero exit code blocks the commit
npm test     || exit 1

# Enable this hooks folder for the repository (run once):
#   chmod +x .githooks/pre-commit
#   git config core.hooksPath .githooks
```

## Sık sorulan sorular

**Bir Git hook'u nasıl atlanır?**

Komuta `--no-verify` ekleyin; örneğin `git commit --no-verify` veya `git push --no-verify`. Ekibinizin güvendiği denetimleri devre dışı bıraktığı için az kullanın.

**Git hook'larını ekibimle nasıl paylaşırım?**

Hook betiklerini depoda `.githooks` gibi bir klasöre commit edin ve her geliştiriciden `git config core.hooksPath .githooks` çalıştırmasını isteyin. Birçok ekip bunu, hook'ları projenin bağımlılıklarıyla birlikte kuran bir hook yöneticisiyle otomatikleştirir.

**En yaygın Git hook'u hangisidir?**

En yaygın kullanılan `pre-commit` hook'udur; genellikle commit edilen dosyalar üzerinde biçimlendiricileri, linter'ları ve hızlı testleri çalıştırmak için kullanılır.

---

Software Dictionary: https://softwaredictionary.org/tr · https://softwaredictionary.org/tr/llms.txt