내가 작성한 branch를 다른 branch와 합치고 싶을 때, 우리는 git merge를 사용한다.
하지만 merge는 용도에 따라 여러 방식으로 가능한데, 이에 대해 알아보자
- Merge commit
- Squash and Merge
- Rebase and Merge
참고로, 아래 예시에서는 base 브랜치를 main으로 설정했지만, 브랜치명을 바꾸면 어떤 브랜치든 베이스 브랜치가 될 수 있다.
git checkout main
git merge {merge하고 싶은 브랜치명}
아래의 사진을 보자. 노란색 하이라이트는 커밋을 한 내역이며, 초록색 하이라이트는 머지를 한 내역이 나타나있다.
이렇게, merge commit은 브랜치 안에서 커밋을 한 내역과 머지를 한 내역, 즉 모든 변경사항이 모두 main(기준 브랜치)에 저장되는 머지 방식이다.
장점:
1. 코드 변경에 대한 가장 자세한 기록을 제공
2.git log --oneline --graph
를 통해 변경 내역과 시기에 대한 정보를 모두 확인할 수 있음
단점:
가독성이 떨어지기 때문에git reset
등 코드를 되돌리고자 할 때 혼란을 야기
git checkout main
git merge --squash {merge하고 싶은 브랜치명}
squash and merge는 말 뜻 그대로 하나로 짓눌러서(?) 머지를 하는 방식이다. 따라서, 브랜치 안에서 진행한 커밋 내역 없이 머지 내역만 남는다,
즉, 위의 사진에서 초록색 내역만 'Squash merge to main'으로 main에 추가된다. (사진과 다름)
장점:
가장 깔끔한 커밋 기록을 유지할 수 있음
단점:
커밋의 세부 정보가 손실되기 때문에, 커밋 기록을 통해 개발 프로세스의 논리 결정 과정 등의 정보를 얻기 어려움
git checkout {merge하고 싶은 브랜치명}
git rebase main
git checkout main
git merge {merge하고 싶은 브랜치명}
Rebase and merge는 Squash and Merge의 정반대의 결과가 나타난다고 이해하면 쉽다.
말 그대로 Rebase, 베이스 브랜치를 변경해주는 커맨드이기 때문에, 커밋의 결과만 베이스 브랜치로 나타나고 머지 내역은 나타나지 않는다.
즉, 해당 그림에서 노란색 하이라이트가 된 내역만 main에 추가된다.
장점:
깔끔하면서도 머지된 브랜치의 세부 커밋 정보가 손실되지 않음
단점:
1. 브랜치가 생성되고 병합된 시기를 알기 어려움
2. 어떤 커밋이 어떤 PR/브랜치와 관련되어 있는지 확인하기 어려움