곰돌푸우❤️

목차

    팀으로 작업을 하다보면 하루에도 수많은 커밋이 쌓이게 됩니다.

    개발하다보면 매번 모든 기능을 테스트 해보기란 쉽지 않은데요.

    버그가 발생했을 때 원인을 찾는 과정에서 유용한 git bisect라는 기능에 대해서 알아보도록 하겠습니다.

     

    배경

    앱의 기능을 테스트 하다가 버그가 발생했다고 가정합니다.

    여기서 이 버그의 원인을 찾기 위해 확인하는 방법은 다음과 같을 것입니다.

     

    의심가는 코드의 위치에서

     

    1. 브레이크 포인트를 걸고 디버깅

    2. git log를 통해 히스토리를 확인

     

    대부분 1, 2의 방법으로 버그의 문제를 발견할 수 있습니다.

     

    하지만 위의 방법으로도 문제를 발견하기 힘든 경우가 있을 수 있습니다.

    그때는 해당 문제를 일으킨 정확한 커밋을 찾아 코드변경 내역을 알아내면 좋습니다.

     

    git bisect 란?

    커밋의 특정 범위 내에서 이진탐색을 통해 문제가 발생한 최초의 커밋을 찾는데 도움을 주는 git의 기능입니다.

     

    git bisect 사용방법

    1. 문제가 발생하는 commit을 찾아 Hash값을 기록해 놓습니다. 1d45c75

     

    2. 문제가 발생되지 않는 commit을 찾아 Hash값을 기록해 놓습니다. 4b58458

     

    3. 아래의 명령어를 차례대로 입력합니다.

     

    # git bisect start
    # git bisect bad 1d45c75
    # git bisect good 4b58458

     

    Bisecting: 7 revisions left to test after this (roughly 3 steps)
    [1c0b7a04ea7802037ec1b1ed0d98ecbfc5f5747d] Commit Message~

     

    라는 문구가 출력이 됩니다. 

     

    이는 bad/good 사이에 7개의 커밋이 있고 bisect를 최대 3번만 더 수행하면 문제의 커밋을 찾을 수 있음을 나타냅니다. 그리고 bisect를 수행할 첫번째 커밋으로 checkout 되면서 커밋의 정보가 출력됩니다.

     

     

    4. 해당 커밋에서 문제가 발생하는 지 확인 후 아래 명령어를 입력합니다.

     

    문제가 여전히 발생하면

     

    # git bisect bad

     

    문제가 발생하지 않으면 

     

    # git bisect good

     

    그러면 2진 탐색을 통해 commit을 계속 찾아나가게 됩니다.

     

    5. 4번을 계속 계속 수행해 나가시다 보면 버그를 발생시킨 최초의 커밋이 출력됩니다.

     

    ccd1a6daca3bf01df7fda12ace86f5d518e9831f is the first bad commit

     

    6. bisect 과정이 모두 끝이나면 아래의 명령어로 초기화를 해줍니다.

     

    git bisect reset

     

    그러면 bisect를 처음시작했던 commit으로 checkout하게 됩니다.

     

    마치며

    이상 git의 bisect를 통해서 문제를 발생시킨 최초의 커밋을 찾아 보았습니다. 때로는 이 기능이 유용하게 사용될 수 있습니다. 꼭 기억해 두셨다가 필요할 때 잘 써먹으시길 바랍니다.

    반응형

    'IT > Git' 카테고리의 다른 글

    fatal: You are in the middle of a cherry-pick -- cannot amend.  (0) 2020.01.03
    facebook twitter googleplus kakaostory naver