Git Hook’ları Kapsamlı Rehber: Kurulum, Kullanım ve İpuçları

Git hook’ları, commit veya push gibi Git eylemlerinden önce ya da sonra betikler çalıştırarak iş akışınızdaki görevleri otomatikleştirmenizi sağlar. Sorunları erken yakalamaya, standartları uygulamaya ve hatta problemleri otomatik olarak düzeltmeye yardımcı olur.

Diyelim ki kod biçimlendirme standartlarını zorlayan bir betik yazdınız. Bu betiği, commit’ten önce çalışan bir hook’a ekleyebilirsiniz. Artık biri commit denediğinde hook devreye girer. Kod, hook’taki kontrollerden geçerse commit gerçekleşir; geçmezse commit engellenir.

Üstelik sadece sorunları işaretlemekle kalmaz. Commit gerçekleşmeden önce bu sorunları düzeltmek için betiği özelleştirebilirsiniz. Bu yazıda Git hook’ları hakkında bilmeniz gereken her şeyi; ne olduklarını, hangilerinin önemli olduğunu ve nasıl etkili şekilde uygulayabileceğinizi ele alacağım.

Git Hook’ları Nedir?

Git hook’ları, bir commit, push veya merge’den önce ya da sonra gibi belirli Git eylemleri gerçekleştiğinde özel betikleri otomatik olarak çalıştırır. Git ile yerleşik gelirler; bu nedenle harici kütüphane kurmanıza gerek yoktur.

Bir Git deposu başlattığınızda, Git varsayılan olarak hook’ları oluşturur. Bunları .git/hooks dizini içinde bulursunuz. Varsayılan olarak çalışmayı engelleyen .sample uzantılarıyla gelirler. Varsayılan olarak çalışsınlar istiyorsanız, .sample uzantısını kaldırmanız yeterlidir.

Hook’ları herhangi bir çalıştırılabilir betik dilinde yazabilirsiniz. Örneğin, pre-commit hook dosyasına, aşamaya alınmış dosyalarda "To-do" yorumlarını arayan ve bulursa commit’i engelleyen bir betik ekleyebilirsiniz. Bu, her commit denemenizde Git’in “To-do” ile başlayan yorumları taradığı ve bekleyen görevler varsa işlemi başarısız kıldığı anlamına gelir. Bu şekilde post-commit, pre-merge, pre-push ve daha fazlası gibi farklı git eylemleri için özel hook’lar oluşturabilirsiniz.

Git Hook Türleri

Uygulamalı örneklere geçmeden önce, iki tür Git hook’unu anlayalım. 

İstemci tarafı hook’lar: kategoriler ve yaygın örnekler

İstemci tarafı hook’lar, commit, rebase ve push gibi Git işlemleri sırasında yerel makinelerde çalışır. İşte bazı popüler istemci hook’ları ve özel kullanım alanları.

• pre-commit: Commit mesajını yazmadan önce çalışır. Commit’ten önce kod stillerini zorlamak, testleri çalıştırmak veya sözdizimi hatalarını kontrol etmek için kullanabilirsiniz. 
• prepare-commit-msg: Git varsayılan commit mesajını oluşturduktan sonra, ancak commit mesajı düzenleyicisi açılmadan önce çalışır. Bu hook, özel betik mantığına göre varsayılan mesajı değiştirebilir veya yenisiyle değiştirebilir. 
• commit-msg: Bu hook, commit mesajı kaydedildikten hemen sonra ancak Git commit’i tamamlamadan önce çalışır. Biçimlendirme, yapı veya etiketleme gibi commit mesajı kurallarını zorlamak için son kontrol noktasıdır.
• post-commit: Bir commit oluşturulduktan sonra çalışır. Genellikle bildirimler (ör. commit sonrası Slack mesajı gönderme) veya günlükleme (commit metaverilerini depolama) için kullanılır.
• post-checkout: Başarılı bir git checkout komutundan sonra çalışır. Bir dalı değiştirdiğinizde veya belirli bir commit ya da yolu checkout ettiğinizde tetiklenir. Proje bağımlılıklarını yeniden kurmak, geçici dosyaları silmek veya yeni bir dal hakkında bildirim yapmak için kullanabilirsiniz.
• post-merge: Başarılı bir birleştirme işleminden sonra çalışır. Genellikle bağımlılıkları güncellemek, birleştirme mesajlarını yazdırmak veya önbellekleri temizlemek için kullanılır.
• pre-rebase: Bir rebase işleminden önce çalışır. Korumalı dallarda rebase’i engellemek, rebase’e izin vermeden önce testleri çalıştırmak veya aşamaya alınmamış değişiklikler varsa rebase’i durdurmak için kullanabilirsiniz.
• pre-push: Değişiklikleri itmeden önce çalışır. Korumalı dallara push’ları engellemeye veya ön-push testleri çalıştırmaya yardımcı olur.
• post-rewrite: Git commit’leri başarıyla yeniden yazdıktan sonra çalışır. git commit --amend (son commit’i yeniden yazar) veya git rebase (bir dizi commit’i yeniden yazar) gibi işlemlerde tetiklenir. Yeniden yazma sonrası referansları güncellemek veya testleri ve CI adımlarını tetiklemek için kullanın.
• pre-applypatch: git am komutu tarafından çağrılır; bir yama çalışma ağacına uygulandıktan sonra ancak yeni bir commit oluşturulmadan önce çalışır. Bu hook’taki kontroller başarısız olursa sıfır olmayan bir durumla çıkabilir ve yamanın commit edilmesini engelleyebilir.
• post-applypatch: Git, yamayı uygulayıp commit oluşturduktan sonra bunu çalıştırır. Commit’i iptal edemez, ancak günlükleme veya bildirim göndermek için uygundur.
• applypatch-msg: Git, git am yamayı uygulamadan önce bunu çalıştırır. Yamaya yönelik önerilen commit mesajını kontrol etmek veya düzenlemek için kullanın.

Sunucu tarafı hook’lar: kategoriler ve kullanım alanları

Sunucu tarafı hook’lar, uzak Git sunucularında çalışır ve bir depoya push etmeden önce ya da sonra gibi uzak olaylar gerçekleştiğinde tetiklenir.

• pre-receive: Uzak depo, push’u kabul etmeden önce bunu çalıştırır. Kullanıcılar arasında tutarlı bir kod stili zorlamak veya bir istemciden gelen değişiklikleri kabul etmeden önce güvenlik kontrolleri yapmak için kullanabilirsiniz.
• update: pre-receive her push için bir kez çalışırken, update hook’u tek bir push’ta değiştirilen her referans (dal veya etiket) için çalışır.
• post-receive: git push işlemi tamamlandıktan sonra çalışır. Genellikle bildirim göndermek, kapsamlı günlükleme yapmak veya CI/CD hatlarını tetiklemek için kullanılır.
• post-update: Git bir push’taki tüm referansları güncelledikten sonra çalışır. her referans güncellemesinin eski ve yeni günlüklerine erişemediği için post-receive’in aksine, basit bildirimler için kullanabilirsiniz.
• reference-transaction: Bir referans işlemi hazırlandığında, işlendiğinde veya iptal edildiğinde tetiklenir; bu nedenle birden fazla kez çalışabilir. Tek bir işlemde birden fazla referansın güncellemelerini doğrulamak ya da reddetmek veya referans değişikliklerini kaydetmek ve denetlemek için kullanın.
• push-to-checkout: Uzakta şu anda checkout edilmiş bir dala git push yaptığınızda tetiklenir. Bu hook ile push sonrası sunucudaki dosyaları güncelleyebilir, değişiklikleri günlükleyebilir veya çalışma dizinine doğrudan yapılan güvensiz push’ları engelleyebilirsiniz.
• pre-auto-gc: Git otomatik çöp toplama tetiklemeden hemen önce çalışır. Çöp toplamayı başlatmayı günlüklemek, kaynak yoğun işlemler sırasında engellemek veya ön-çöp toplama görevlerini ele almak için kullanabilirsiniz.
• proc-receive: git-receive-pack komutu gelen bir push’u işlerken çalışır. Uzak depodaki referansları (dallar ve etiketler) günceller ve sonuçları istemciye bildirir.

Git Hook’larının Kurulumu

Bu bölümde git hook’larını kurma ve ayarlama adımlarını bulacaksınız. Ayrıca sıfırdan özel hook’ların nasıl oluşturulacağını da göreceksiniz. 

Kurulum ve yapılandırma mekaniği

Bir Git deposu başlattığınızda, Git otomatik olarak .git/hooks klasörü içinde bir dizi hook oluşturur. Bunları görmek için terminalinizi açın ve git init çalıştırdığınız deponun kök dizinine gidin. Buradan, gizli .git dizinini ve ardından hooks alt dizinini açın. Basit bir cd komutu bunu sizin için yapar ve hooks alt dizinine erişim sağlar.

cd .git/hooksAltyapı:

İçeri girdikten sonra, .sample uzantısına sahip varsayılan hook’ları göreceksiniz. Varsayılan bir hook’u etkinleştirmek için bu uzantıyı kaldırın ve çalıştırılabilir yapın.

Örneğin, pre-commit hook’undan .sample uzantısını kaldırmak için aşağıdaki komutu kullanın.

mv .git/hooks/pre-commit.sample .git/hooks/pre-commitAltyapı:

Ardından, aşağıdaki komutla çalıştırılabilir yapın:

chmod +x .git/hooks/pre-commitAltyapı:

Bu, varsayılan hook’ları düzenleme ve etkinleştirme konusunu kapsar. Özel hook’ları sıfırdan oluşturmak için şu adımları izleyin.

.git/hooks/ içinde yeni bir dosya açmak için şunu çalıştırın:

nano .git/hooks/commit-msgAltyapı:

Betiği bu dosyada oluşturun. Örnek:

 #!/bin/sh
echo "✅ Commit message hook triggered"Altyapı:

Kaydedip çıkın, ardından çalıştırılabilir yapın:

chmod +x .git/hooks/commit-msg Altyapı:

Yukarıdaki örnekte, commit başarılı olduğunda hook’lar " Commit message hook triggered" mesajını yazdırır

Özel hook’ları kurmanın başka bir yolu daha vardır. Bir depo başlattığınızda, Git varsayılan hook’ları içerir. Bu varsayılanları şablon dizinleri kullanarak düzenleyebilirsiniz. 

Şöyle çalışır: git init çalıştırdığınızda, Git, global şablon dizininin içeriğini yeni deponun .git/ dizinine; hook’lar dahil kopyalar. Özel hook betiklerini global şablon dizinine eklerseniz, oluşturduğunuz her yeni depo bu özel hook’ları otomatik olarak miras alır.

Hook betiklerini oluşturma ve özelleştirme

Önce neyi başarmak istediğinizi belirlemeniz gerekir. Belirsiz commit mesajlarını yakalamak, yanlışlıkla push’ları önlemek veya önbellekleri temizlemek mi? Amacın baştan belirlenmesi önemlidir; çünkü farklı git hook’ları farklı amaçlara hizmet eder ve hangisini kullanacağınızı bilmelisiniz. 

Örneğin, commit mesajı stilini kontrol etmek istiyorsanız commit-msg hook’unu kullanırsınız. Ana dala belirli push’ları önlemek istiyorsanız, bunu bir pre-push hook’uyla yapmalısınız. 

Hook’u seçtikten sonra sıradaki karar dildir. macOS ve Linux’ta küçük bir Bash (veya düz sh) betiği çoğu zaman yeterlidir. Windows’ta bazı ekipler PowerShell kullanır. 

Depo çok dilli ise, herkesin aynı mantığı çalıştırabilmesi için Python veya Node.js gibi evrensel bir yorumlayıcıyı tercih edebilirsiniz. Bu nedenle, Git’in nasıl çalıştıracağını bilmesi için en üste bir shebang (#!/bin/sh, #!/usr/bin/env python3 vb.) eklemek anahtardır.

.env dosyalarının commit edilmesini engelleyen basit bir pre-commit hook örneği. Bu, hassas API anahtarlarının yanlışlıkla push edilmesini önler.

#!/bin/sh

# Block committing secrets
if git diff --cached --name-only | grep -q ".env"; then
  echo "❌ .env file detected in commit! Remove it before committing."
  exit 1
fi

exit 0Altyapı:

Hook’ları devre dışı bırakmak istediğinizde, en kolay yol onları geçici olarak yeniden adlandırmak (pre-commit → pre-commit.off) veya çalıştırma izinlerini kaldırmaktır. 

Ancak yalnızca bir kez atlamak gerekiyorsa, commit hook’larını atlamak için git commit --no-verify ve push hook’larını atlamak için git push --no-verify kullanın. Hatta git config core.hooksPath /dev/null ile Git’i boş bir klasöre yönlendirerek hook’ları global olarak devre dışı bırakabilirsiniz.

Git Hook’larının Yaygın Kullanım Alanları ve Örnekler

Git hook’ları özellikle testleri, güvenlik kontrollerini otomatikleştirmek ve iş akışınızda kalite standartlarını uygulamak için faydalıdır. 

Pratik otomasyon senaryoları

Kod stili veya linting uygulama: Pre-commit hook’u genellikle kod biçimlendirmeyi otomatikleştirmek ve commit gerçekleşmeden önce potansiyel hataları yakalamak için kullanılır.

Örneğin, aşağıdaki pre-commit hook’unda prettier biçimlendirmeyi otomatik olarak yapar ve commitlemeden önce değişiklikleri aşamaya alır. Ardından bir linter çalıştırılabilir ve commit yalnızca linting geçerse başarılı olur. Başarısız olursa commit durdurulur.

#!/bin/sh

# Collect staged JS/TS files
FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(js|ts|tsx)$')
[ -z "$FILES" ] && exit 0

echo "Formatting with Prettier..."
npx --yes prettier --write $FILES

# Re-stage files that Prettier changed
echo "$FILES" | xargs git add

echo "Linting with ESLint..."
npx --yes eslint $FILES
STATUS=$?

if [ $STATUS -ne 0 ]; then
  echo "ESLint found issues. Fix them or commit with --no-verify if needed."
  exit $STATUS
fi

echo "Pre-commit checks passed."
exit 0Altyapı:

Otomatik testleri çalıştırın: Herhangi bir değişikliği push etmeden önce otomatik testleri çalışacak şekilde hook’ları ayarlayabilirsiniz. Örneğin, aşağıdaki pre-push hook’u, push etmeden önce depodaki mevcut pytest’leri otomatik olarak keşfeder ve çalıştırır.

#!/bin/sh
echo "Running tests before push..."
pytest -q
STATUS=$?
[ $STATUS -eq 0 ] || { echo "Tests failed. Push aborted."; exit $STATUS;Altyapı:

Hassas verilerin commit edilmesini otomatik olarak engelleyin: .env, .pem veya .key gibi dosyalar genellikle sırlar içerir. Aşağıdaki pre-commit hook örneği bu tür kalıpları kontrol eder ve içeriyorsa commit’i engeller.

#!/bin/sh
set -e

STAGED=$(git diff --cached --name-only --diff-filter=ACM)

# Block dotenv and private keys
echo "$STAGED" | grep -E '\.env(\.|$)|(^|/)\.env$|\.pem$|\.key$|id_rsa$' >/dev/null 2>&1 && {
  echo "Sensitive file detected in staged changes. Remove it from the commit."
  exit 1
}Altyapı:

Etkili Git Hook’ları Yazmak İçin İpuçları

Burada, Git hook’ları yazarken faydalı bulduğum bazı ipuçlarını paylaşıyorum. 

Hook’ları hızlı tutun

Hook’lar belirli Git eylemlerini her tetiklediğinizde çalışır; bu nedenle hafif olmalarını sağlayın. Büyük test paketleriniz varsa daha iyi performans için bunları yerel hook’lar yerine CI’da çalıştırın. Her commit’te tüm depoda linter, biçimlendirici veya kontrolleri çalıştırmak sizi yavaşlatır; kontrolleri gerçekten değişen dosyalarla sınırlayın.

Platformlar arası uyumluluğu koruyun 

Hook’larınızın farklı işletim sistemlerinde sorunsuz çalıştığından emin olun. Taşınabilir shebang’ler kullanın, satır sonlarını tutarlı yönetin (CRLF yerine LF kullanın) ve mutlak yolları sabitlemeyin. 

Bunun yerine PATH ve npm run lint veya python -m gibi yerel proje betiklerine güvenin ki birden fazla ortamda çalışsın.

Hata ayıklama stratejileri

Betiklerin nasıl çalıştığını izlemek için ayrıntılı günlükleme veya bir hata ayıklama bayrağı (örneğin, HOOK_DEBUG=1) ekleyin. Geçerli dizin, dal veya aşamaya alınan dosyalar gibi ayrıntıları yazdırın. Bu, yürütme akışını takip etmeyi ve sorunların nerede ortaya çıktığını görmeyi kolaylaştırır.

Hook’ları farklı girdilerle test edin ve değişiklikleri push etmeden önce yerelde başarısızlık senaryolarını simüle edin. Bir hook beklenmedik şekilde ilerlemeyi engellerse, Git’in --no-verify bayrağıyla veya hook’ları atlamak için tasarlanmış ortam değişkenleriyle geçici olarak atlayabilirsiniz.

İşletim sistemleri arasında tutarlı davranış için, işletim sistemine özgü komutlardan kaçının ve taşınabilir betik dillerini tercih edin.

Hook’ları net biçimde belgelendirin

İyi dokümantasyon ekip anlayışını artırır ve yeni üyelerin uyumunu kolaylaştırır. Her hook’un amacını, davranışını ve kullanımını açıklayan merkezi bir README tutun. Nasıl çalıştırılacağı, önkoşullar, sorun giderme ve atlama ipuçlarını ekleyin. Ayrıca kurulum/ayar talimatlarını sağlayın. 

Git Hook’ları İçin Gelişmiş Uygulama Teknikleri ve En İyi Uygulamalar

Daha ileri düzey bir kullanıcıysanız, şu ipuçları yardımcı olabilir:

Performans optimizasyonu

Karmaşık iş akışlarında performansı optimize etmek için ağır kütüphanelerden kaçınarak harici bağımlılıkları azaltın. Bu, başlatma süresini kısaltır ve hata noktalarını azaltır. 

Linting gibi maliyetli işlemlerin sonuçlarını önbelleğe alın; dosyalar değişmediyse yeniden kullanın. 

Hook’lar birden fazla kontrol içeriyorsa, aynı anda çalışmaları için paralelleştirin. Ayrıca hook betiklerini modülerleştirin. Yani hook’ları, bağlama göre yalnızca ilgili parçaları çalıştıran, yeniden kullanılabilir küçük bileşenler olarak yapılandırın.

Hook zincirleme ve orkestrasyon

Tek bir git olayında birden çok hook çalıştırmak için zincirlemeyi kullanın. Örneğin, bir pre-commit hook’unda önce linting, sonra test, ardından kod biçimlendirme gibi adımları zincirleyebilirsiniz. Her komut ardışık çalışır ve biri başarısız olursa (sıfır olmayan durumla çıkarsa) sonraki komutlar atlanarak hatalı commit önlenebilir. 

Hook eylemleri birbirinden bağımsızsa zamandan tasarruf etmek için paralel de çalıştırabilirsiniz. Bu noktada görev yürütmesini doğru sırada yönetmek için orkestrasyondan yararlanırsınız.

Yapılandırma yönetimi 

Her deponun kendi .git/hooks dizini vardır. Yani aynı kontrolleri (ör. linting) birden çok projede istiyorsanız her yere kopyala-yapıştır yapmanız gerekir. Daha iyi bir yol, hook’ları merkezi olarak yönetmek ve tüm depoların bunlara erişip çalıştırmasını sağlamaktır.

Bunu tek bir komutla yapabilirsiniz:  git config --global core.hooksPath ~/.githooks. Bu, Git’e hook’ları ~/.githooks klasöründe aramasını söyler. Oraya oluşturduğunuz tüm hook’lar, tüm depolarınız arasında otomatik olarak paylaşılır.

Yapılandırma dosyaları (JSON veya YAML) ile hook mantığını daha dinamik hale de getirebilirsiniz. Her depo için farklı mantığı betiğe sabitlemek yerine, hook betiği o deponun yapılandırma dosyasını okuyup doğru kuralları otomatik olarak uygulayabilir.

Koşullu yürütme

Hook betikleri içinde yalnızca ilgili olduğunda çalışmaları için basit koşullar ekleyebilirsiniz. Bu, geçerli dal adını kontrol etmek, gerçekten değişen dosyalara bakmak veya atlamalarını söyleyen bir ortam değişkeni okumak olabilir.

Daha fazla kontrol istiyorsanız, hangi hook’ların hangi aşamada çalıştığını bir yapılandırma dosyasında bildirdiğiniz pre-commit gibi bir çerçeve kullanın. Ayrıca yalnızca belirli dallarda çalıştırmak, değişkenlerle hook’ları atlamak veya hatta zamana dayalı koşullar eklemek gibi koşullu mantık da katabilirsiniz. Bu, hook betiklerinizi dinamik ve gerçek iş akışlarına uygun hale getirir.

İşbirliği ve paylaşım stratejileri 

Git hook’larını merkezileştirip depolar ve ekipler arasında paylaşmanın iki yolu vardır:

Git şablonları

Bir depo başlattığınızda, Git varsayılan şablonundan git/hooks dizini altına bazı varsayılan hook’lar ekler.

Özel hook’ları merkezi olarak oluşturmak için bir Git şablon dizini oluşturabilir, hook’larınızı oraya yazabilir ve Git’i global olarak bu yeni dizini varsayılan şablon olarak kullanacak şekilde ayarlayabilirsiniz. 

git config --global init.templateDir /path/to/hooks-templateAltyapı:

Ancak bu yöntem, hook’lar için sürüm kontrolü sağlamaz. Hook’larınız nadiren değişiyorsa bu özellikle kullanışlıdır. Hook’ları sık sık güncelliyor ve sürüm kontrolüne ihtiyaç duyuyorsanız, bunun yerine bir sonraki yöntemi kullanmak isteyeceksiniz.

Merkezi git deposu

Ayrı, sürüm kontrollü, merkezi bir depo oluşturun ve tüm özel hook betiklerinizi proje depolarından ayrı olarak bu depoda saklayın. Böylece hook güncellemelerini proje kod tabanından bağımsız yapabilirsiniz. 

Bu hook’lar standartlaştırılmalıdır; yani tek bir depoya bağlı yolları veya değerleri sabitlemekten kaçının.

Bu kurulum özellikle ekipler için kullanışlıdır; çünkü herkes düzenli olarak güncellemeleri çekebilir ve projelerine senkronize edebilir. 

Daha verimli bir yaklaşım, merkezi hook deposunu klonlayan ve hook betiklerini her projenin .git/hooks dizinine kopyalayan bir kurulum betiği kullanmaktır. Örnek kurulum betiği: 

#!/usr/bin/env bash
set -euo pipefail

# Location of the shared hooks template repo
HOOKS_TEMPLATE_REPO="[email protected]:your-org/git-hooks-template.git"
HOOKS_TEMPLATE_DIR="$HOME/.git-hooks-template"

# Clone or update the template repo
 echo "Cloning hooks template repo..."
 git clone "$HOOKS_TEMPLATE_REPO" "$HOOKS_TEMPLATE_DIR"

# The repo where you want hooks installed
TARGET_REPO="${1:-$(pwd)}"
TARGET_HOOKS_DIR="$TARGET_REPO/.git/hooks"

# --- Copy strategy ---
echo "Copying hooks into $TARGET_HOOKS_DIR..."
cp -r "$HOOKS_TEMPLATE_DIR/"* "$TARGET_HOOKS_DIR/"

# 4. Make sure hooks are executable
chmod +x "$TARGET_HOOKS_DIR"/* || true

echo "✅ Hooks installed successfully into $TARGET_REPO"Altyapı:

Başka bir seçenek de sembolik bağlar (symlink) kullanmaktır. Her projenin .git/hooks dizinini, sürüm kontrollü hook deponuzdaki betiklere bağlayabilirsiniz. Böylece merkezi depoyu güncellediğinizde, symlink orayı işaret ettiği için hook’lar otomatik olarak güncellenir.

Bu sistemin güvenilir kalması için hook’ları sürdürmeye yönelik net bir süreç kurun. Ekip üyeleri hook değişikliklerini pull request ile önermeli, yalnızca incelemeden sonra birleştirmeli ve hook’lar geliştikçe dokümantasyonu güncel tutmalıdır. 

Git Hook’larını Geliştirme İş Akışlarıyla Entegre Etme

Git hook’ları, sürekli entegrasyonda (CI) büyük rol oynar. Bağlam için CI, değişiklikleri sık sık birleştirmek ve sorunları erken yakalamak amacıyla derlemeleri ve testleri çalıştırmak demektir. Jenkins, GitHub Actions veya GitLab CI gibi CI/CD araçlarıyla hook’ları bağlayarak, Git olaylarına göre derlemeleri tetikleyebilir, testleri çalıştırabilir ve hatta uygulamaları otomatik olarak dağıtabilirsiniz.

Örneğin, sunucu tarafı bir pre-receive hook’u, bir push’u kabul etmeden önce Git sunucusunda özel bir betik çalıştırır. Betik başarısız olursa sunucu push’u reddeder. Bunu, push’a izin vermeden önce o daldaki son CI derlemesinin geçip geçmediğini kontrol etmek için kullanabilirsiniz. Bu CI çalıştırması; kod kapsamı kontrolleri, birim veya entegrasyon testleri, hatta güvenlik taramalarını içerebilir.

Hook’lar dağıtım görevlerini de otomatikleştirebilir. Bir post-receive hook’u, bir CI/CD hattını başlatan bir webhook tetikleyebilir. Kod ana dala birleştirildiğinde, otomatik olarak derleme → dağıtım → yayın döngüsünü başlatır.

Güvenlik Hususları ve En İyi Uygulamalar 

Daha kolay işbirliği ve ortak gerçeklik için merkezi hook’lar tutuyorsanız, yetkisiz erişimi önlemek amacıyla hook dizininin güvenli dosya izinlerine sahip olduğundan emin olun. Yalnızca güvenilir kullanıcıların yazma erişimi olmalıdır. 

Hook betiklerinizin aldığı girdileri veya parametreleri her zaman doğrulayarak kod enjeksiyonu saldırılarından kaçının. Örneğin, yalnızca harf-rakam ve tire içeren dal adlarına ya da vMAJOR.MINOR.PATCH ile eşleşen etiketlere izin vererek girdileri sıkı kalıplara göre doğrulayın. 

Hook betiklerinde asla hassas verileri sabitlemeyin. Bunun yerine, kimlik bilgilerini çalışma zamanında güvenle sağlamak için ortam değişkenleri veya özel gizli yönetim araçları kullanın. Commit etmek üzere olduğunuz değişikliklerde hassas bilgileri taramak için pre-commit hook’larıyla Gitleaks gibi araçları entegre edebilirsiniz.

Biri hook’unuzu farklı bir sunucuya kod veya bilgi gönderecek şekilde yönlendirebilir. Bu yüzden hook’larınızın erişebileceği etki alanlarını sınırlayın. Bilinmeyen hedef sunucuları engellemek için bir proxy veya güvenlik duvarı kullanın. Ayrıca günlüklerinizin görüntü mesajlarında gizli bilgileri göstermediğinden emin olun. 

Sonuç

Git hook’ları, görevleri otomatikleştirmenin ve standartları doğrudan geliştirme iş akışınızda uygulamanın güçlü bir yoludur. Kod stilinden testlere, dağıtımdan güvenlik kontrollerine kadar her şeye yardımcı olurlar.

Onları doğru kullanarak hataları azaltır, zaman kazanır ve ekipler arası işbirliğini daha sorunsuz hale getirirsiniz.

Basit pre-commit kontrolleriyle başlayın, ardından orkestrasyon, merkezi yönetim veya CI/CD entegrasyonları gibi daha gelişmiş kurulumlarla deney yapın. Git kullanıcısıysanız ve becerilerinizi ilerletmek istiyorsanız, bu ileri Git kursuna göz atın.