git bisect: Hatanın Hangi Commit’te Girdiğini Dakikalar İçinde Bulmak

git bisect, bir hatanın hangi commit ile girdiğini ikili arama yaparak bulan bir Git komutudur. Elle arandığında yüzlerce denemeye çıkabilecek bir iş, bisect ile logaritmik sayıda adıma iner: 300 commit için yaklaşık dokuz deneme yeter.

Ön koşul: net bir kontrol

Yöntemin tek gerçek şartı, "hata var mı yok mu" sorusunu kesin biçimde cevaplayabilmenizdir. Bu bir test, bir betik ya da elle yapılan bir kontrol olabilir; önemli olan kararsız kalmamaktır. Kararsız (flaky) bir testle arama yapmak sizi yanlış commit'e götürür — bu yüzden kırılgan testler burada doğrudan bir engeldir.

Elle kullanım

# 1) Aramayı başlat
git bisect start

# 2) Şu anki durum bozuk
git bisect bad

# 3) Çalıştığını BİLDİĞİNİZ bir noktayı işaretle (etiket, tarih veya commit)
git bisect good v1.8.0

# Git ortadaki commit'e geçer; siz test edip cevap verirsiniz:
#   git bisect good   → bu commit'te hata YOK
#   git bisect bad    → bu commit'te hata VAR
# ... yaklaşık log2(N) tekrardan sonra:
#   "abc1234 is the first bad commit"

# 4) Bittiğinde normale dön
git bisect reset

Tam otomasyon: git bisect run

Kontrolü bir betiğe dönüştürebiliyorsanız süreci tamamen otomatikleştirebilirsiniz. Betik 0 döndürürse commit iyi, sıfırdan farklı bir değer döndürürse kötü sayılır.

#!/usr/bin/env bash
# kontrol.sh — bisect için tek bir hatayı sınar

# Bağımlılıklar commit'ler arası değişmiş olabilir
composer install --no-interaction --quiet || exit 125   # 125: "bu commit denenemez, atla"

# Yalnızca ilgili testi çalıştır: tüm paketi koşmak gereksiz yavaşlatır
vendor/bin/phpunit --filter testSiparisToplamiDogruHesaplanir

chmod +x kontrol.sh
git bisect start HEAD v1.8.0        # bad ve good'u tek satırda ver
git bisect run ./kontrol.sh          # gerisi otomatik
git bisect reset

"İyi commit" seçimi en kritik karar

Arama yalnızca verdiğiniz aralıkta yapılır. İyi olarak işaretlediğiniz commit aslında hatalıysa, sonuç yanlış çıkar. Emin değilseniz aralığı geniş tutun — birkaç fazladan adım, yanlış sonuçtan çok daha ucuzdur.

# Belirli bir tarihteki commit'i bulmak
git rev-list -n 1 --before="2026-05-01" main

# Aralıkta kaç commit var? (deneme sayısı ≈ log2 bu sayı)
git rev-list --count v1.8.0..HEAD

Bulduğunuz hata üretimde etki yaratıyorsa önce müdahale sırası izlenmeli; üretim hatasını hızlı daraltma yazımız bu sırayı veriyor.

Aramayı kolaylaştıran commit disiplini

Yöntemin verimi, geçmişin kalitesine doğrudan bağlıdır. Her commit'in kendi başına derlenip test edilebilir olması gerekir; "yarım iş" commit'leri arama sırasında sürekli 125 döndürür ve süreç yavaşlar. Aynı şekilde dev birleştirme commit'leri, hatayı tek bir değişikliğe indirgemenizi engeller — bulunan "kötü commit" içinde 40 dosya varsa iş bitmemiş demektir.

Bu yüzden küçük ve odaklı commit'ler, dallanma stratejinizden bağımsız olarak değerlidir. Rebase mi merge mi tartışmasında da doğrusal geçmişin en somut faydalarından biri budur: arama çok daha temiz çalışır.

Aramayı hızlandıran bir başka etken, her commit'in testlerinin hızlı çalışmasıdır; sorgu sayısını sabitlemek test sürelerini de kısaltır.

Bulduktan sonra

Hatalı commit'i bulmak işin yarısıdır. İkinci yarısı, o commit'in neden hataya yol açtığını anlamaktır — çünkü doğrudan geri almak bazen başka bir şeyi kırar.

git show abc1234 --stat          # hangi dosyalar değişmiş?
git show abc1234 -- app/Services # yalnızca ilgili dizindeki değişiklik

# Güvenli düzeltme: değişikliği geri alan YENİ bir commit üret
git revert abc1234

Hata ayıklama alışkanlıklarının genel çerçevesi için hata ayıklamada zaman kurtaran alışkanlık yazımıza bakabilirsiniz. Komutun tüm seçenekleri resmî git bisect belgelerinde listelenmiştir.

Sonuç

Bir regresyonun kaynağını bulmak, çoğu ekibin en çok zaman kaybettiği işlerden biridir; oysa Git bunun için hazır bir araç sunuyor. Kullanmanın önündeki tek gerçek engel, hatayı kesin ayırt eden bir kontrol yazmaktır — ve o kontrol zaten yazılması gereken testin kendisidir. Aralığı geniş tutun, kontrolü betiğe dönüştürüp git bisect run ile otomatikleştirin, test edilemeyen commit'lerde 125 döndürün. Bir sonraki "bu ne zamandan beri bozuk?" sorusunda saatlerce log okumak yerine dokuz denemede cevabı bulacaksınız.