커밋 내역 관리를 위한 git merge, rebase, squash

공동 작업 혹은 버전 관리를 위해 커밋 내역을 깔끔하게 해야 한다고들 한다. 개인적으로는 혼자서 하는 작업이라도 커밋 내역을 알아보기 쉽게 관리하는 습관을 들이는 것이 중요하다고 생각한다. 어제 내가 작성한 코드도 기억이 잘 나지 않는데 몇 달 전 남긴 커밋들이 과연 어떤 작업들이었는지 한눈에 알아볼 수 있을까. 의미 있는 커밋을 남기고 메시지를 직관적으로 작성하며 내역을 관리하는 것은 아주 중요하다.

 

커밋 내역을 관리하기 위한 방법은 여러가지가 있다. 나는 보통 squash를 사용하여 의미 없는 커밋들을 합하고 rebase 하여 일렬로 커밋들을 정렬했다. merge 커밋이 남지 않기 때문에 깔끔하고 구현 순서를 의도에 따라 정렬할 수 있어 좋다고 생각했기 때문이다. 인턴쉽을 진행했던 기업에서는 rebase를 따로 하지 않고 깃허브에서 merge시 squash and merge를 사용했다.

 

이유를 물었을 때 사수님께서 커밋을 남길 때마다 의미있는 작업을 한 것이기에 하나의 커밋으로 합하되 그 기록은 남겨서 추후에 어떤 작업을 했는지를 확인하기 위해서라고 하셨다. 설명을 들으니 명확하게 이해가 갔다. 즉, 상황에 따라 커밋 내역 관리법을 선택하면 된다. 일반적으로는 본인이 속한 기업의 문화에 따르게 되긴 한다.

 

main 브랜치에서 A1, A2... 라는 작업을 하고 B 기능을 구현하기 위해 feature-b 브랜치를 생성했다. 다음과 같은 상황에 merge, rebase, squash을 적용한 상황을 예시로 들겠다.

 

git merge

 

main 브랜치에서 feature-b 브랜치를 merge를 하게 되면 merge 커밋이라는 커밋 하나가 추가로 생성된다. 이는 feature-b와 main 브랜치가 병합되었음을 나타내는 이력이다.

 

git rebase

 

feature-b 브랜치에서 main 브랜치를 rebase 하면 위의 그림과 같이 정렬된다. 대상 브랜치를 base삼아 현재 작업 중인 브랜치의 커밋 이력을 재정렬 하는 것이다. rebase를 하게 되면 브랜치의 커밋들의 해시 값이 변경된다. B1', B2'가 된다. merge와 달리 기능 브랜치에서 커밋 관리를 하는 것이 다른데 main 브랜치에서도 rebase를 할 수 있다. 그러나 만약 옮기려는 main 브랜치의 커밋 중에 다른 분기를 가진 커밋이 포함되어 있다면 큰 문제를 불러올 수 있다. 그러니 main 브랜치에서 rebase의 사용은 지양하는 것이 좋다.

 

git squash

 

사실 squash 작업은 rebase 과정에 포함되어 있다고 말할 수 있다. 단순히 브랜치만 따서 base를 재정렬하는 작업뿐만 아니라 여러 커밋을 하나로 합한 후에 base를 바꿀 수도 있다. 이렇게 커밋들을 하나로 합하는 명령이 squash이다. 그 후에 재정렬된 모습이 위의 그림이다. 즉, squash and rebase라고 볼 수 있다.

 

 

 

 

 

* 아래의 자료들을 참고하였습니다.

git merge와 git rebase의 차이 - Blog