🏭 현재 프로젝트
나는 GitPractice라는 프로젝트를 만들어서 커밋을 1부터 20까지 쌓아놓았다. 이 프로젝트로 실습을 진행하려고 한다.
🤯 현재 상황
프로젝트를 작업하다가 오류가 나버린 상황이다. 분명 이전에 되는 것을 확인했었는데 어느 순간부터 꼬인 건지 모르는 상황이라고 가정해 보자. 당장 커밋을 20개까지 한 상황이기 때문에 어느 커밋에서 문제가 생겼는지 모르는 상황이다.
이럴 경우 아주 좋은 해결방법 중 하나가 git bisect라는 것이다. 이제부터 어떻게 git bisect로 이 상황을 해결해 볼 수 있는지 알아보자.
🤓 git bisect
git bisect start를 해보자.
시작해 보니 <B>라는 모양이 보이는데 Bisect의 약자인 B로 보인다. waiting for both good and bad commits라는 문구가 있다. 현재 커밋에서 문제가 생겼으니 git bisect bad를 해보자.
그렇게 되면 waiting for good commits, bad commit known이라고 나온다. 좋은 커밋을 하나 달라는 것이다. 이 상황에서 나는 1번 커밋이 좋은 커밋이라고 하고 bisect를 진행해보겠다.
물론 칸이 20개가 되지 않지만 20개라고 가정하고 1번 커밋으로 이동해서 git bisect good을 써보면...
위와 같이 본격적인 탐색이 시작된다! 나는 1번은 good, 20번은 bad라고 했는데 10번 커밋으로 이동했다.
10번 커밋도 good이라고 하니까 15번 커밋으로 이동했다. 이쯤에서 bisect의 원리를 눈치챌 수 있을 것 같다.
바로바로 이분탐색이다. 문제가 발생한 첫 번째 커밋을 찾는 과정이 이분탐색이 가능한 조건을 모두 만족한다. good, bad로 구분되고, 첫 번째 bad를 찾는 과정이기 때문이다.
🏁 git bisect의 결과
결국 아래와 같이 탐색하게 된다면 first bad commit을 알려주게 된다. 나는 그러면 이곳과 다음커밋에서부터 문제를 찾아나갈 수 있다!
git bisect log를 찍어보게 된다면...
20 → 1 → 10 → 15 → 12 → 14 → 13 → 14 의 과정으로 문제가 생긴 커밋을 효과적으로 찾는 것을 볼 수 있다. 20개의 커밋을 확인해봐야 하지만 7번의 과정으로 줄이게 되었다. 이것은 커밋의 개수가 많을수록 더 그 효과를 볼 수 있다.
bisect를 끝내고 싶다면 git bisect reset으로 종료해 주면 다시 main branch HEAD로 돌아오게 된다.
