#주저리주저리
저번 글에서는 git add, commit, push 등의 동작에 대해서 알아보았다.
이번에는 먼저 브랜치 병합에 차근차근 알아보자!
브랜치란?
브랜치를 분리하면 안전한 백업본을 마련해두고 작업을 할 수 있다는 점과 협업 시 독립적인 환경에서 작업할 수 있다는 점에서 강한 장점을 지닌다.
비슷한 맥락에서 Prod, Release, Dev서버 등으로 분리하여 CI/CD를 적용하고 배포하는 관점에서도 반드시 사용되는 개념 중 하나이다.
이처럼 강력한 브랜치 기능을 Git에서는 파일을 복사하여 저장하는 것이 아니라, 스냅샷 형태로 관리하여 사용자는 부담없이 브랜치를 늘려 사용할 수 있다.
하지만 브랜치를 무작정 늘리기만 해서는 의미가 없음!
협업은 각자 개인 프로젝트해서 결과물을 내는 것이 아니라 하나의 결과물을 내기 위함이다.
따라서 각각 분리된 브랜치에서 작업한 내역을 다시 공유 브랜치로 옮겨오는 작업이 필수적이다.
브랜치 병합 방법
Git에서 다른 브랜치에서 작업한 내용을 통합하기 위해서 사용되는 방법은 크게 Merge와 Rebase가 있다.
두 가지 방법은 기능적으로는 동일하지만, 각각 뚜렷한 장점과 단점이 있다.
- Rebase
- 커밋 히스토리를 깔끔하게 관리할 수 있다
- merge에 비해 어렵고 자칫 위험할 수 있다
- Merge
- 커밋 히스토리가 드럽다...
- 쉽고 안전하게 통합시킬 수 있다
Git Merge 동작 방식
그렇다면 왜 이런 차이가 발생하는 것일까?
우선 우리가 그나마 친숙한 Merge부터 케이스별로 나눠서 알아보자!
Case 1. Fast-Forward Merge
이 경우에는 git merge의 단점인 커밋 히스토리가 더러워지는 현상은 발생하지 않는다.
간단하게 설명해보자면 두 브랜치의 마지막 커밋 포인터가 분리되지 않고 하나의 포인터가 다른 포인터의 조상인 경우 해당 머지 방식이 발생한다. 단순히 기존 브랜치의 커밋 포인터를 이동시키기만해도 정상적으로 병합된다.
예를 들어 Main branch에서 Hotfix branch를 파서 급하게 수정하고 Main에서는 추가적인 커밋이 일어나지 않은 경우에 발생한다.
Main branch가 fast-forward되어 Hotfix 브랜치와 같은 커밋을 가르키는 것으로 브랜치 병합작업이 완료된다.
Case 2. 3-Way-Merge
일반적으로 협업하는 환경에서 Git Merge를 하면 가장 많이 발생하는 방식이다.
이 경우가 우리가 바로 Git Rebase를 사용해야하는 이유!
바로 위에서, 두 브랜치의 마지막 커밋 포인터가 분리되지 않은 경우, Fast-Forward Merge가 발생한다고 했다. 즉, 3-Way-Merge는 마지막 커밋 포인터가 서로 분리되어 커밋 이력이 쌓여있는 상태에서 발생한다.
상황을 가정해보자, Dev 브랜치에서 Feature1과 Feature2 브랜치를 파고, Feature1 브랜치 작업이 이미 끝나서 이미 Dev에 통합시킨 상황이다. 여기서 Feature2 브랜치의 작업본을 Dev 브랜치에 병합하려고 하면, 두 브랜치의 커밋 이력이 상이하여 단순히 Fast-Forward 방식으로는 병합하지 못한다.
이 때, 양쪽의 변동 내역을 담은 또 다른 Commit을 하나 생성하여 이를 Dev branch에 담아주어 정상적으로 병합을 완료할 수 있다.
여기서 우리는 단순히 Git Merge만 사용하게 되면 일반적인 경우, 무의미한 커밋 이력이 추가되어 커밋 히스토리가 더러워진다는 것을 알 수 있다.
마무리
이번에 Git branch 기능을 사용하는 이유와 Git Merge의 각 조건별 동작 방식에 대해 알아보았다.
다음에는 Git Rebase를 통해 3-Way-Merge가 발생하지 않도록 해결하는 방법에 대해 알아보자 :)
