CLIGitbisect회귀버그
git bisect로 회귀 버그가 시작된 commit을 찾는 CLI 프롬프트
변수 입력4개
변수를 채운 뒤 완성본을 복사하세요
언제 사용하나
예전에는 정상이었던 기능이 어느 시점부터 깨졌고 변경 commit이 많을 때, git bisect로 범위를 반씩 줄여 첫 회귀 commit을 찾는다.
준비할 정보
{{GOOD_REF}}: 정상이 확인된 commit·tag{{BAD_REF}}: 문제가 재현되는 commit·branch{{TEST_COMMAND}}: 성공 0, 회귀 1을 반환하는 결정적 명령{{SETUP_COMMAND}}: commit별 build·dependency 설치가 필요할 때만 사용
복사해서 쓰는 CLI agent 프롬프트
{{GOOD_REF}}에서는 정상이고 {{BAD_REF}}에서 실패하는 회귀의 첫 commit을 git bisect로 찾아줘.
판별 명령: {{TEST_COMMAND}}
준비 명령: {{SETUP_COMMAND}}
1. 저장소 지침과 `git status` 부터 확인해. 미커밋 변경이 있으면 stash·reset하지 말고 중단해.
2. {{GOOD_REF}}와 {{BAD_REF}}에서 같은 환경과 입력으로 판별 명령을 실행해 진짜 good/bad인지 검증해.
3. 테스트가 flaky하면 bisect를 시작하지 말고 먼저 반복 실행으로 안정화해.
4. `git bisect start {{BAD_REF}} {{GOOD_REF}}`를 실행하고 각 commit에서 판별 근거를 기록해.
5. build 불가와 회귀 실패를 구분하고 판별할 수 없는 commit은 `git bisect skip`으로 처리해.
6. 자동화를 쓴다면 script와 exit code를 보여준 뒤 `git bisect run`을 실행해.
7. 첫 bad commit을 찾은 후 diff와 의도를 분석하고 `git bisect reset`으로 원래 branch로 복귀해.
8. 버그 수정은 별도 승인 전에 시작하지 마.
결과: 'good/bad 검증 / 판별 명령 / 검사한 commit / 첫 bad commit / 근거 diff / 복귀 상태 / 수정 후보'안전 체크
- submodule, generated file, migration으로 commit별 준비 절차가 다르지 않은지 확인한다.
- 테스트가 외부 API나 공유 DB를 변경하지 않게 격리한다.
- bisect 완료 후 branch와 working tree가 시작 전 상태인지 확인한다.
관련 자료
- git bisect: https://git-scm.com/docs/git-bisect
댓글 0개
아직 댓글이 없습니다.