센로그

[ED] 26. 버전 관리 시스템으로 버그 원인과 히스토리 추적하기 본문

Effective/Effective Debugging

[ED] 26. 버전 관리 시스템으로 버그 원인과 히스토리 추적하기

seeyoun 2024. 11. 19. 01:07

버전 관리 시스템에 기록된 파일의 변경 내역을 분석하면 버그가 언제 어떻게 생겼는지 알아낼 수 있다.

  • 버전 관리 시스템을 활용하여 정상적인 버전과 버그가 있는 버전을 비교한다.

 


버그 분석에 유용한 깃 명령어들

  • 새로운 버그를 발견했다면 먼저 이전 버전에서 어떤 부분을 변경했는지 살펴본다.
    • git log
  • 발생한 문제와 관련된 파일을 찾았다면 그 파일에 대한 변경 사항만 자세히 살펴본다.
    • git log path/to/myfile.js
  • 발생한 문제가 코드의 특정 라인에 관련되어 있다고 의심되면, 해당 코드에 대한 어노테이션 정보를 출력해서 각 라인에서 가장 최근 발생한 변경 사항을 자세히 살펴본다.
    • git blame path/to/myfile.js
    • 해당 파일 내부 또는 여러 파일 사이에서 이동한 라인을 추적하려면 -C와 -M 옵션을 지정한다.
  • 문제와 관련된 부분이 코드에서 삭제됐다면 과거에 삭제된 내용을 뒤져본다.
    • git rev-list -all | xargs git grep 삭제된_메서드_이름
  • 문제가 발생하기 바로 전 버전을 알고 있다면 그 버전 이후에 변경된 내역을 살펴본다.
    • 가령 V1.2.3 이후에 문제가 발생했다면 다음과 같이 실행한다.
    • git log V1.2.3..
  • 어느 버전인지는 정확히 모르지만 해당 문제가 발생한 날짜는 알고 있다면 그 날짜 바로 전에 커밋한 SHA 해시를 알아낸다.
    • git rev-list -n 1 --before=2015-08-01 maseter
    • 이렇게 구한 SHA 해시를 버전 문자열 대신 사용한다.
  • 문제가 특정한 이슈를 해결한 뒤에 발생했다면 해당 이슈에 관련된 모든 커밋을 검색한다.
    • 가령 이슈 1234번을 해결한 커밋의 메시지에 'Issue #1234'라는 문자열이 담겨 있다면 다음 명령을 실행한다.
    • git log -all --grep='Issue #1234'
  • 살펴보려는 커밋에 대한 SHA 해시를 알고 있다면 해당 커밋에서 변경한 내역을 살펴볼 수 있다.
    • 가령 살펴보려는 커밋의 해시가 1cb6e3f6이라면 다음 명령을 실행한다.
    • git show 1cb6e3f6
  • 두 버전 사이에 일어난 변경 사항을 보려면 다음과 같이 실행한다.
    • git diff V1.2.3..V1.3.2
  • 가령 버그가 발생한 버전의 구간을 알고 있고, 오류가 발생하면 0이 아닌 코드를 반환하며 종료하는 테스트 스크립트도 있다면, 그 버전 사이에서 발생한 모든 변경 내역을 이진 탐색으로 검색해서 해당 버그를 발생시킨 지점을 찾아준다.
    • git bisect start V1.1.0 V1.2.3
      git bisect run test.sh
      git reset

 

Comments