[Git] merge 외의 branch를 합치는 또 다른 방법 Rebase와 Squash

출처 https://gist.github.com/mitchellh/319019b1b8aac9110fcfb1862e0c97fb

 

Merge

새로운 커밋을 생성하여 병합된 브랜치의 내용을 기록하게 된다.
히스토리를 유지하고 되돌리기 편하다는 장점이 있지만 다른 방법들에 비해 히스토리가 많이 남으므로 복잡해 보일 수 있다.

 

 

Rebase

Rebase는 브랜치의 시작점을 새롭게 조정한다. 
커밋들이 유지되며 병합 커밋이 생성되지 않고,
병합할 가지의 최신 커밋이 새로운 시작점이 되기 때문에 한줄로 깃이 유지되어 깔끔해보인다는 장점이 있다. 
하지만 다른 개발자들과 협업할 때 Rebase를 사용할 경우, 공유된 브랜치의 히스토리가 변경될 수 있어 주의해야한다.

git checkout sub_branch
git rebase develop
git checkout develop
git merge sub_branch

 

 

Squash and Merge

Squash and Merge는 기존의 머지방식대로 새로운 커밋을 생성하여 병합된 브랜치의 내용을 기록한다.
하지만 기존의 머지와 다르게 따로 작업한 이전의 히스토리내역들과 연결이 끊어진다는 특징이 있다.
작은 단위의 롤백이 어렵다는 단점이 있다.

git checkout main               // main 브랜치로 이동해서
git merge --squash my-branch    // my-branch 브랜치에 대한 통합 커밋을 생성하고 
                                   main 브랜치에 병합하기 위한 명령
git commit -m "commit message"  // 통합 커밋을 생성

 

 

언제 어떤 방식을 사용해야하는지

 

팀의 방식과 개인의 선호 등 여러 방식에 따라 달라질 수 있다.

적절하게 적합한 방식을 선택하여 사용하는 것이 좋은데,

Git Flow 를 따른다고 했을 때, 아래와 같이 정리할 수 있다.

• develop - feature 브렌치간 머지 : Squash and Merge가 유용합니다. feature의 복잡하고 지저분한 커밋 히스토리를 모두 묶어 완전 새로운 커밋으로 develop 브렌치에 추가하여, develop 브렌치에서 독자적으로 관리할 수 있기 때문입니다. 일반적으로 머지 후에 feature 브렌치를 삭제해버리는 점을 떠올려 보면, feature 브렌치의 커밋 히스토리를 모두 develop 브렌치에 직접 연관 지어 남길 필요가 없습니다.
• master - develop 브렌치간 머지 : Rebase and Merge가 유용합니다. develop의 내용을 master에 추가할 때에는 별도의 새로운 커밋을 생성할 이유가 없기 때문입니다.
• hotfix - develop, hotfix - master 브렌치간 머지 : Merge 또는 Squash and Merge 모두 유용합니다. 때에 따라 골라 사용하면 좋을 것 같습니다. hotfix 브렌치 작업의 각 커밋 히스토리가 모두 남아야 하는 경우 Merge, 필요 없는 경우 Squash and Merge를 사용하면 됩니다.

또한

한 브랜치 내에서 cli의 interactive rebase (ex, git rebase -i HEAD~5)와
reword(커밋메세지변경 키워드), squash(여러커밋을묶어주는 키워드)를 사용해서 커밋히스토리 정리도 가능하다.

자세한 방법은 https://meetup.nhncloud.com/posts/122 가장 하단에 나와있다

 

 

 

참고

https://hudi.blog/git-merge-squash-rebase/

https://meetup.nhncloud.com/posts/122