[git] 문제의 시초를 잡는 조력자 git bisect

 
 

어느날 사수가 링크 하나를 보내왔다. 현생 살이가 바쁘다는 핑계로 따로 시간을 내어 공부하지 않는 나같은 게으름뱅이에게는 이런 정보 하나하나가 꿀이므로 바로 흡수에 들어간다. 사수 본인이 버그픽스를 위해 깃 히스토리를 거슬러 올라갈 때 요긴하게 사용한다며 칭찬에 마지않았던 그 기술 git bisect. 잊지 않기위해 여기에 기록 해본다. 
 
 
 

git bisect, 언제 필요할까?

 

내 상황을 예로 들어보자면, 우리회사는 네 개의 프로젝트를 팀원들이 돌아가며 작업하는데(딱히 룰은 없고 하고싶은거 골라잡으면 됨) 어느날 오랜만에 넘겨받은 프로젝트에서 오류가 발견될 때가 있다. 왜 하필 내가 손을 대야하는 순간에 버그가 출현하는걸까? 이유야 어찌되었건 원인을 찾아내야 하는 사람은 나다. 커밋이 서너개 정도 되면 해쉬넘버(고유번호)를 하나씩 거슬러 올라가 확인하면 되지만 만약 몇달만에 이 프로젝트를 맡게 되었고 그 사이 300개의 커밋이 추가되었다면? 아프다 아프다 골치가 아프다. 하지만 망하란 법은 없다고 git bisect 을 쓰면 300번의 커밋을 Binary(이진법) 으로 확인해 우리의 정신건강을 지키는데 어느정도 도움을 받을 수 있다. 
 
 
 

그래서 git bisect 가 뭔데?

bisect 라는 단어를 사전에 검색해 보면 정확하게 두 개로 나눈다는 의미를 가지고 있다. 이걸 깃 커밋 히스토리에 그대로 적용시켜 커밋 수를 절반으로 나누어 한쪽을 훑고 또 절반으로 나누어 훑고 훑다 보면 예를들어 1024개의 커밋이 있다면 이걸 대략 10번 만에 훑어 문제의 커밋을 찾아낼 수 있게 한다. 확인해야하는 커밋들 리스트에서 처음과 끝을 지정해주고 그 안에서 나누고 나누고 또 나누는데 이 기준이 bad commit과 good commit이다. 최신커밋, 그러니까 내가 버그를 발견한 현 시점의 커밋을 bad commit으로 지정해 주고 버그가 존재하지 않는 commit, 혹은 그마저도 확인할 길이 없는 극한의 상황에선 맨 처음 commit까지 거슬러 올라가서 얘를 good commit으로 지정해 준다. 그러면 git bisect가 몇 번의 확인을 거칠건지 계산해주고 얘가 리드하는데로 커밋을 확인해나가다 보면 마지막에 문제의 근원지인 커밋을 찾아내 프린트 해 준다. 이렇게 텍스트로만 읽어서는 이해가 잘 가지 않으니 (사실 나도 이해하는데 한참 걸렸다) 예시와 함께 설명해 보겠다.
 
 
 

여기 리액트 기본 탬플릿이 있다. 그런데 뭔가 어색하지 않은가? 짙은 회색이어야 할 배경이 보라색이다. 여기서는 이 보라색 배경을 버그로 칭하겠다. 우리의 목표는 이 프로젝트의 전체 커밋을 훑어 버그(보라색 배경)을 만들어낸 최초의 bad commit을 찾아내는 것이다. 
 
 
 

먼저 커밋 히스토리를 출력해보면 이 프로젝트에 더해진 커밋이 10개임을 알 수 있다. git bisect start 를 터미널에 타이핑 해 git bisect를 사용하겠다고 알린다. 
 
 
 

그리고 good commit과 bad commit을 지정해 준다. good과 bad 중 아무나 먼저 지정해줘도 된다. (최초의 good commit과 bad commit이 지정되는 순간부터 git bisect이 우리를 그 가운데 커밋으로 널뛰기 시키기 시작할 것이다.) 여기서는 첫번째로 bad 커밋을 해당 최신 브런치의 해쉬넘버와 함께 git bisect bad hashnumber 로 지정 해 준 뒤 첫번째 커밋을 역시 같은 방법이지만 good commit으로 다음줄에 타이핑 해 줬다. 엔터를 치면 바로 다음줄에 git bisect이 good commit과 bad commit 사이에 몇 개의커밋이 있고 앞으로 몇 단계의 커밋을 체크할 것인지 보여준다. 그리고 HEAD를 우리가 지정한 good commit과 bad 커밋의 중간으로 이동시켜 놓았으니 해당 커밋이 버그가 포함된 bad commit인지 good commit인지 확인하라고 한다. 
 
 
 

커밋 내용을 확인해보니 배경과 관련된 내용이 없다. 여전히 배경이 회색이므로 good commit으로 지정하고나니 바로 일곱번째 커밋으로 보내버린다. 일곱번째도 버그가 안보이므로 good commit으로 지정해주면 된다.
 
 
 

그렇게 git bisect이 이끄는대로 흘러가다보면 어느순간 버그가 포함된 커밋이 나타난다. 얘를 bad commit으로 지정해주고 다시 git bisect에 흐름을 맡긴다.
 
 
 

어느새 HEAD는 여덟번째 커밋으로 이동하고 여기서부터 더이상의 수정사항은 없고 마지막 스탭이라고 한다. 여덟번째 커밋의 배경도 보라색이다. bad commit 확정!
 
 
 

그럼 git bisect이 다시한번 얘가 최초의 bad commit을 만들어 낸 범인이라고 상기시켜준다.
 
 
 

git show를 타이핑 해 이 커밋에 어떤 업데이트가 있었는지 확인한다.
 
 
 

범인이 누구인지 알았으니 git bisect reset을 해줘 다시 최근 커밋으로 돌아가면 끝. 
 
 
 
 
git basect를 공부하면서 헷갈렸던 부분은 오류자체를 깃이 파악해주는건 줄 알았는데 그건 아니고 인간이 알아서 찾아내야 한다. git bisect는 그저 중간커밋으로 이동시켜줘 진범을 찾아내는 시간을 단축시켜주는 역할을 할 뿐이다. 자동화 시키는 방법도 있다는데 여기까지는 사실 귀찮아서 보지 않았다. 히스토리를 잘 모르는 프로젝트를 넘겨받았을 때 버그 트래킹 하기 요긴한 git bisect 에 대해 간단히 정리해 보았다.