언제부터 버그가 생겼는지 모를 때 git bisect로 찾는 법

문제 발생

한 달 전에는 잘 되던 기능이 지금은 깨져 있는 걸 발견했는데, 그 사이 커밋이 300개가 넘어 어느 커밋에서 문제가 생겼는지 감이 안 잡히는 상황이었습니다.

원인 분석

이런 상황에서 커밋을 하나씩 순서대로 확인하면 최악의 경우 300번을 확인해야 합니다. git bisect는 "현재는 버그가 있다", "과거 특정 시점에는 버그가 없었다"는 두 지점만 알면, 그 사이를 이진 탐색으로 좁혀갑니다. 300개 커밋이면 log2(300) ≈ 9번 정도의 확인만으로 원인 커밋을 찾을 수 있습니다.

해결 방안

1. bisect 세션을 시작하고, 현재(버그가 있는) 상태를 bad로, 문제가 없었던 과거 커밋을 good으로 표시합니다.

git bisect start
git bisect bad                # 현재 커밋은 버그가 있음
git bisect good v1.2.0        # 이 태그/커밋 시점에는 버그가 없었음

2. Git이 자동으로 두 지점의 중간 커밋으로 체크아웃합니다. 그 커밋에서 직접 테스트해보고 결과를 알려줍니다.

# 테스트해본 뒤
git bisect good   # 이 커밋엔 버그가 없다면
# 또는
git bisect bad    # 이 커밋에 버그가 있다면

3. 이 과정을 반복하면 Git이 계속 범위를 절반씩 좁혀가며 최종적으로 "이 커밋이 처음으로 버그를 만들었다"는 결과를 알려줍니다.
4. 확인 과정이 스크립트로 자동화 가능하다면(예: 특정 테스트가 실패/성공하는지), git bisect run <스크립트>로 전체 과정을 자동화할 수 있습니다 — 스크립트가 exit code 0이면 good, 0이 아니면 bad로 자동 판정합니다.

git bisect run npm test -- --testPathPattern=regression.test.ts

5. 원인 커밋을 찾은 뒤에는 git bisect reset으로 원래 브랜치로 돌아갑니다.

git bisect reset

공식 문서

• Git Docs: git-bisect
• Pro Git Book: Debugging with Git