Merge 전략의 존재
과거 협업 프로젝트를 진행하면서 나름의 Branch 전략을 세워서 진행을 했던 경험이 있다.
전략이라기보단... 개인 브랜치를 생성해서 따로 작업을 하다가 merge 하는 방식이었는데
merge 도 개인이 PR 을 날리고 셀프 merge 시키곤 했다...
그러다 보니 생긴 Github 뱃지들
뱃지 설명을 보니 뭔가 내 멋대로 해서 준 것 같아서 찾아보니
- YOLO - 코드 리뷰 없이 머지 시켰을 때
- Quickdraw - PR 오픈하고 5분 안에 닫았을 때
얻을 수 있다고 한다.
"PR 오픈하고 코드 리뷰 없이 5분 만에 Merge 시킴"
딱 내가 한 그대로이다!
현업에서 이런 식으로 허술하게 할 리는 없고, 내 프로젝트를 봐주신 어느 감사한 현업자님께서 프로젝트 진행 시에 Git 을 제대로 이용하지 못한 것 같다는 피드백을 받고 Git 에 대해 더 자세히 살펴보기로 했다.
종류
구글링을 해보니 크게 4가지로 나눌 수 있다.
- Git Merge (Fast-Forward)
- Git Merge (Recursive)
- Git Rebase
- Git Squash
하나씩 살펴보기 전에 우선 프로젝트 파일을 하나 만들고 커밋 해주었고 b1 이라는 브랜치를 생성하였다.
Git Merge (Fast-Forward)
- git checkout -b 브랜치 이름 으로 브랜치 생성 후 checkout 한다. (*여기서 새로운 브랜치 이름 : b1)
- b1 브랜치에서 3개의 커밋을 진행한다.
- git checkout main 후 git merge b1 으로 merge 한다.
- Merge 전
- Merge 후
가장 기본적인 Merge 방식으로 main 에서 새로운 브랜치로 분리해 작업을 하고 다시 main 브랜치로 merge 하는 방식이다.
커밋을 그대로 옮기는 방식이기 때문에 커밋의 해쉬값이 동일하다.
Fast-Forward Merge 방식은 별도의 merge commit 이 생성되지 않기 때문에 언제 merge 가 이뤄졌는지 알기가 힘들다는 단점이 있다.
Merge commit 을 생성하기 위해선 Fast-Forward Merge 가 가능한 상태에서 git merge 에 --no--ff 옵션을 주어 commit 을 생성할 수 있다.
Git Merge (Recursive)
- b1 브랜치에서 2개의 커밋을 진행한다.
- main 브랜치에서 2개의 커밋을 진행한다.
- git merge b1 으로 merge 한다.
- (같은 파일 수정시) 발생하는 conflict 을 resolve 한다.
- Merge 전
같은 파일을 수정하여 conflict 이 발생하였다.
main 파일을 선택하고 conflict Resolve
- Merge 후
Fast-Forward 때와는 달리 커밋 메세지가 새로 생성되었고 커밋 해쉬값도 다르게 설정된 것을 확인할 수 있다.
대부분의 협업 프로젝트에서 일반적으로 가장 많이 사용하는 Merge 방식이다.
장점
- 커밋 진행 상황을 쉽게 확인 가능하다.
- 여러 개의 브랜치의 커밋 내역이 전부 남아있다.
단점
- 커밋 내역이 전부 남기 때문에 브랜치와 커밋이 많아질수록 내역이 복잡해진다.
- 생성되는 머지 커밋들이 너무 많아질 수 있다.
Git Squash
- b1 브랜치에서 2개의 커밋을 진행한다.
- main 브랜치에서 1개의 커밋을 진행한다.
- git merge b1 으로 merge 한다.
- (같은 파일 수정시) 발생하는 conflict 을 resolve 한다.
- Merge 전
- Merge 후
일반 머지를 할 때와는 다르게 b1 의 브랜치 라인이 이어지질 않는다.
조금 모호해보여 Github Desktop 으로 비교를 해보았다.
main 브랜치 커밋 이력을 보면
Recursive Merge 는 b1 의 커밋 내역이 그대로 남아있지만
Squash Merge 에서는 b1 의 커밋 내역은 사라지고 머지가 된 것을 확인할 수 있다.
장점
- 커밋 히스토리가 간결하다.
- 머지 커밋이 생성되어 언제 머지가 되었는지 확인이 가능하다.
단점
- 일반 머지보다 커밋 내역이 디테일하지 않다.
- 여러 커밋이 squash 되어 합쳐지기 때문에 문제 발생시 원인을 찾기 어려울 수 있다.
Git Rebase
- Merge 전
b1 브랜치에서 rebase 를 진행시켜 주면 conflict 이 발생하게 된다.
conflict 을 해결해주고
- Merge 후
b1 브랜치에서 main 으로 rebase 된 것을 확인할 수 있다.
장점
- 간결한 커밋 히스토리
- 머지 커밋 없이 깔끔한 커밋 내역을 확인 가능하다.
단점
- rebase 시 커밋 히스토리가 변경되므로 다른 사용자들로 하여금 혼란을 초래할 수 있다.
- conflict 발생시 해결이 다소 까다롭다.
참고
https://ssocoit.tistory.com/273
https://leetrue.hashnode.dev/branch-merge-strategy
https://velog.io/@bae-sh/Git-merge%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC
https://dev.to/ctnkaan/difference-between-git-merge-rebase-and-squash-3kg4