Quick Flow

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으로 판정을 script에 위임할 수 있지만 flaky test는 먼저 안정화하거나 반복 실행 policy를 둡니다.

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

# test.sh 종료 코드: 0 good, 1..124 bad, 125 skip, 126 이상 abort

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

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

skip으로 판정 불가 commit을 건너뛸 수 있다

중간 commit이 compile error나 dependency 문제로 실행되지 않으면 good/bad 판정이 불가능합니다. 이때 git bisect skip 또는 script의 exit code 125를 쓰면 그 commit을 건너뜁니다. skip이 많으면 Git은 원인을 하나로 특정하지 못하고 candidate range를 보고할 수 있으므로, build 가능 범위를 먼저 좁히거나 manual verification을 추가합니다.

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

체크포인트

주의할 점

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

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