빠른 흐름

git bisect start
git bisect bad                # 현재 상태가 문제 있음
git bisect good v1.2.0        # 확실히 정상이었던 태그 또는 커밋

# Git이 중간 커밋을 checkout해 줌
# 테스트 후 판정
git bisect good    # 또는 git bisect bad

# 원인 커밋이 특정되면 출력됨
git bisect reset   # 원래 브랜치로 복귀

진단 흐름

어떤 버그 추적 흐름을 먼저 떠올리면 되나

이분 탐색은 커밋 수에 무관하게 log₂(N) 번만 판정하면 된다

직접 커밋을 하나씩 확인하면 1,000개 커밋에서 최대 1,000번 확인해야 하지만, git bisect는 이분 탐색이므로 10번 안에 범위를 특정할 수 있습니다. 커밋 히스토리가 길어질수록 이 차이가 기하급수적으로 커집니다. Git은 good/bad 판정을 받을 때마다 내부적으로 commit 객체 DAG를 탐색해 중간 지점을 결정하므로, 사용자가 직접 커밋 ID를 계산할 필요가 없습니다.

# 커밋 1,000개짜리 히스토리라면
1,000개 수동 확인  →  최대 1,000번
git bisect         →  최대 10번 (log₂ 1000 ≈ 10)

판정 기준이 흔들리면 bisect 결과도 신뢰할 수 없다

bisect의 핵심 전제는 "good 커밋과 bad 커밋 사이에 정확히 하나의 전환점이 있다"는 가정입니다. 재현 절차가 환경에 따라 달라지거나, 버그가 산발적으로 나타나는 타이밍 문제라면 판정이 엇나가 잘못된 커밋이 원인으로 지목될 수 있습니다. 자동화 테스트가 있으면 git bisect run으로 판정 자체를 스크립트에 위임할 수 있어 가장 안전합니다.

# 판정을 스크립트로 자동화
git bisect run ./test.sh

# test.sh 종료 코드 0 → good, 비0 → bad로 자동 처리

수동 판정보다 bisect run이 안정적일 때가 많다

재현 절차가 명확한 테스트로 고정될 수 있다면 사람이 매번 눈으로 판단하는 것보다 git bisect run이 낫습니다. 수동 판정은 "이번엔 좀 느리지만 괜찮은가?" 같은 흔들림이 생기기 쉽고, 그 순간 bisect 결과 전체가 흔들립니다. 반대로 UI 확인처럼 자동화가 어려운 경우엔 수동 판정이 필요하지만 good/bad 기준을 먼저 문장으로 고정해 두는 편이 안전합니다.

skip으로 빌드 깨진 중간 커밋을 건너뛸 수 있다

중간 커밋이 컴파일 에러나 의존성 문제로 아예 실행이 안 되는 경우, good/bad 판정이 불가능합니다. 이때 git bisect skip을 쓰면 그 커밋을 후보에서 제외하고 탐색을 이어갑니다. skip이 너무 많으면 정확도가 낮아지므로, skip 대상 범위를 커밋 범위로 한번에 처리하는 편이 낫습니다.

git bisect skip                        # 현재 커밋 skip
git bisect skip a1b2c3d..e4f5g6h       # 범위 전체 skip

체크포인트

주의할 점

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

# 어떤 커밋에서는 "가끔 실패"를 bad로 보고,
# 어떤 커밋에서는 같은 증상을 good으로 처리하면
# 결과 전체가 흔들림