Git히스토리와 복구

bisect로 버그 범위 좁히기

어느 커밋에서 버그가 들어왔는지 모를 때, 이분 탐색 방식으로 문제 커밋 범위를 빠르게 좁히는 `git bisect` 흐름을 정리합니다.

마지막 수정 2026년 3월 22일

기본 패턴

text
git bisect start
git bisect bad
git bisect good v1.2.0

설명

  • 버그가 분명히 있는데 어떤 커밋에서 들어왔는지 감이 안 잡힐 때, 커밋을 순서대로 하나씩 보는 것은 너무 느립니다. git bisect는 이분 탐색으로 범위를 빠르게 줄여 줍니다.
  • 흐름은 단순합니다. 현재 상태를 bad로 표시하고, 확실히 정상이었던 과거 지점을 good으로 표시하면, Git이 중간 지점을 checkout해 줍니다. 사용자는 그 지점이 good인지 bad인지 계속 판정하면 됩니다.
  • 이 과정의 핵심은 "판정 기준이 명확해야 한다"는 점입니다. 테스트가 있으면 가장 좋고, 없더라도 재현 절차가 일관돼야 bisect가 의미를 가집니다.
  • git bisect는 히스토리를 읽는 명령이 아니라, 버그 탐색을 자동화하는 명령에 가깝습니다. 그래서 Git 사용이 디버깅 방식 자체를 바꾸는 대표적인 예이기도 합니다.
  • 회귀(regression) 버그를 다룰 일이 많다면 bisect는 투자 가치가 아주 큽니다. 커밋이 많아질수록 사람이 느끼는 체감 효율 차이가 크게 납니다.

빠른 정리

단계의미
git bisect startbisect 시작
git bisect bad현재 상태를 문제 있음으로 표시
git bisect good <commit>과거 정상 지점 표시
반복Git이 중간 지점 제안, 사용자가 판정
git bisect reset종료 후 원래 브랜치로 복귀

주의할 점

bisect는 "good인지 bad인지"를 안정적으로 판정할 수 있을 때 가장 강력합니다. 테스트나 재현 절차가 흔들리면 중간 판정이 틀어져 결과 신뢰도도 떨어질 수 있습니다.

참고 링크

2 sources