저는 IOS 시뮬레이터에서 ReactNative 코드를 수정하며 앱 개발을 하고 있었습니다. Native코드를 건들지도 않았고, JS코드만 작성했기에 당연히 Android에서도 잘 작동할 것이라고 예상했습니다. 하지만 Android에서 앱을 빌드하자 크래시가 나서 앱이 종료되는 심각한 문제가 발생했습니다. 다행히 저는 git에 코드를 commit 해놓았기에 버전을 돌려가면서 문제를 찾으면 되었습니다.
제가 사용한 방법은 git bisect
버그가 발생한 시점을 빠르게 찾는 Git 명령어입니다.
원리
작동 원리는 간단합니다 — 이진 탐색(binary search).
좋았던 커밋과 나빴던 커밋을 기준으로,
Git이 중간 커밋을 자동으로 체크아웃하며
“이 커밋도 버그가 있나요?”를 반복 질문합니다.
이 과정을 통해
100개의 커밋 중에서도 단 7번 정도의 테스트만으로
문제를 유발한 커밋을 정확히 찾아낼 수 있습니다.
사용법
-
bisect 모드 시작
git bisect start -
현재 커밋(버그가 존재하는 상태)을 ‘bad’로 지정
git bisect bad
3.정상 작동하던 커밋(버그가 없던 시점)을 ‘good’으로 지정
git bisect good <커밋명>
-
Git이 자동으로 중간 커밋으로 이동한다.
그럼 직접 테스트 후 문제가 된 커밋이 이 버전인지 판단한다. -
버그가 있으면:
git bisect bad
버그가 없으면:git bisect good을 입력한다.
그럼 다시 4번으로 되돌아가서 Git이 자동으로 중간 커밋으로 이동, 사용자는 판단한다.
- 반복을 통해 문제 커밋이 확인되면 종료한다.
git bisect reset
예시
가정: 프로젝트의 커밋 히스토리가 다음과 같다고 합시다.
A — B — C — D — E — F — G (HEAD)
A: 프로그램이 잘 동작하던 초기 커밋 ✅
G: 현재 버그가 발생한 최신 커밋 ❌
이제 git bisect로 버그 커밋을 찾아봅시다.
1. bisect 시작
git bisect start
git bisect bad G
git bisect good A
Git은 A~G 사이의 중간 커밋 D로 자동 이동합니다.
2. 중간 커밋(D) 테스트
프로그램을 실행해 봤더니 버그가 있다면?
git bisect bad
버그가 없다면?
git bisect good
3. Git의 다음 단계
Git은 남은 커밋 중 중간으로 이동합니다.
예를 들어,
D가 bad라면 → A~D 사이에서 다시 중간(B 또는 C)로 이동
D가 good이라면 → D~G 사이에서 다시 중간(E 또는 F)로 이동
이 과정을 반복합니다.
4. 결과
몇 번 테스트 후 Git이 다음 메시지를 출력합니다:
<commit_hash> is the first bad commit
즉, 버그를 처음 만든 커밋이 바로 그 지점입니다.
자동화: git bisect run
테스트 과정을 자동으로 처리하고 싶다면?
예를 들어,
npm test로 버그 발생 여부를 판단할 수 있을 때
자동 실행 명령을 지정할 수 있습니다.
git bisect start
git bisect bad
git bisect good A
git bisect run npm test
Git은 각 커밋에 대해 npm test를 실행하고
테스트가 실패하면 bad, 성공하면 good으로 자동 판정합니다.
테스트가 끝나면 원래 브랜치 상태로 복귀합니다.
git bisect reset
✅ 결론
git bisect는 디버깅의 시간 복잡도를 선형에서 로그 수준으로 줄여주는 강력한 도구입니다.
특히 팀 프로젝트나 오픈소스 개발처럼 커밋이 많은 환경에서
“언제부터 깨졌는가?”를 찾는 데 드는 시간을 극적으로 절약할 수 있습니다.
