git bisect run 자동 이등분
./test종료 상태가 0 인 자동화 된 스크립트 가있는 경우 테스트가 정상이면 다음을 통해 버그를 자동으로 찾을 수 있습니다 bisect run.
git checkout KNOWN_BAD_COMMIT
git bisect start
# Confirm that our test script is correct, and fails on the bad commit.
./test
# Should output != 0.
echo $?
# Tell Git that the current commit is bad.
git bisect bad
# Same for a known good commit in the past.
git checkout KNOWN_GOOD_COMMIT
./test
# Should output 0.
echo $?
# After this, git automatically checks out to the commit
# in the middle of KNOWN_BAD_COMMIT and KNOWN_GOOD_COMMIT.
git bisect good
# Bisect automatically all the way to the first bad or last good rev.
git bisect run ./test
# End the bisect operation and checkout to master again.
git bisect reset
이것은 물론 테스트 스크립트 ./test가 git track되면, bisection 동안 이전 커밋에서 사라지지 않는다고 가정합니다.
인 트리 스크립트를 트리에서 복사하고 PATH비슷한 변수로 재생하고 대신 거기에서 실행하면 매우 자주 벗어날 수 있습니다 .
물론, 테스트 인프라가 test이전 커밋에 영향을 미치는 경우 솔루션이 없으므로 커밋을 하나씩 테스트하는 방법을 결정하여 수동으로 작업을 수행해야합니다.
그러나이 자동화를 사용하면 종종 작동하며 작업 백 로그에 누워있는 느린 테스트의 경우 시간을 절약 할 수 있다는 것을 알았습니다. 시도.
더 많은 팁
bisect 후 다음으로 돌아 가지 않고 첫 번째 실패 커밋을 유지하십시오 master.
git bisect reset HEAD
start+ 이니셜 bad과 good한 번에 :
git bisect start KNOWN_BAD_COMMIT KNOWN_GOOD_COMMIT~
와 같다:
git checkout KNOWN_BAD_COMMIT
git bisect start
git bisect bad
git bisect good KNOWN_GOOD_COMMIT
지금까지 테스트 한 내용을 참조하십시오 (수동 good및 bad또는 run).
git bisect log
샘플 출력 :
git bisect log
git bisect start
# bad: [00b9fcdbe7e7d2579f212b51342f4d605e53253d] 9
git bisect bad 00b9fcdbe7e7d2579f212b51342f4d605e53253d
# good: [db7ec3d602db2d994fe981c0da55b7b85ca62566] 0
git bisect good db7ec3d602db2d994fe981c0da55b7b85ca62566
# good: [2461cd8ce8d3d1367ddb036c8f715c7b896397a5] 4
git bisect good 2461cd8ce8d3d1367ddb036c8f715c7b896397a5
# good: [8fbab5a3b44fd469a2da3830dac5c4c1358a87a0] 6
git bisect good 8fbab5a3b44fd469a2da3830dac5c4c1358a87a0
# bad: [dd2c05e71c246f9bcbd2fbe81deabf826c54be23] 8
git bisect bad dd2c05e71c246f9bcbd2fbe81deabf826c54be23
# bad: [c536b1b7242d5fcf92cd87e9a534bedb1c0c9c05] 7
git bisect bad c536b1b7242d5fcf92cd87e9a534bedb1c0c9c05
# first bad commit: [c536b1b7242d5fcf92cd87e9a534bedb1c0c9c0
더 나은 시간 개념을 얻으려면 git log에 좋고 나쁜 참조를 표시하십시오.
git log --decorate --pretty=fuller --simplify-by-decoration master
이것은 해당 참조를 가진 커밋 만 보여 주어 노이즈 그리스를 줄이지 만 자동 생성 된 참조 유형은 포함합니다 :
refs/bisect/good*
refs/bisect/bad*
어느 커밋이 좋거나 나쁘다고 표시되었는지 알려줍니다.
명령을 가지고 놀고 싶다면 이 테스트 저장소를 고려하십시오 .
실패는 빠르고 성공은 느리다
때때로:
- 첫 번째 테스트 중단 중 하나와 같이 오류가 빠르게 발생합니다.
- 실패한 테스트 패스 및 우리가 신경 쓰지 않는 다른 모든 테스트와 같이 성공하는 데 시간이 걸립니다.
이러한 경우, 예를 들어 실패가 항상 5 초 안에 발생한다고 가정하고 실제로 테스트를 더 구체적으로 작성하기가 게으른 경우 다음과 같이 사용할 수 있습니다 timeout.
#!/usr/bin/env bash
timeout 5 test-command
if [ $? -eq 1 ]; then
exit 1
fi
이 때문에 작동 timeout종료 124의 실패하면서 test-command종료 1.
매직 이탈 상태
git bisect run 종료 상태에 대해 약간 까다 롭습니다.
127 이상이면 이분법이 다음과 같이 실패합니다.
git bisect run failed:
exit code 134 from '../test -aa' is < 0 or >= 128
특히, C assert(0)는 a로 이어지고 SIGABRT상태 134로 빠져 나와 매우 성가시다.
125는 마법이며으로 달리기를 생략합니다 git bisect skip.
이 목적은 관련없는 이유로 인해 손상된 빌드를 건너 뛰는 데 도움이됩니다.
자세한 내용 man git-bisect은 참조 하십시오.
따라서 다음과 같은 것을 사용하고 싶을 수도 있습니다.
#!/usr/bin/env bash
set -eu
./build
status=0
./actual-test-command || status=$?
if [ "$status" -eq 125 ] || [ "$status" -gt 127 ]; then
status=1
fi
exit "$status"
자식 2.16.1에서 테스트되었습니다.