🙃 Intro

프로젝트를 진행하다가 main, develop 브랜치의 커밋 로그가 너무 복잡한 것을 느꼈다.
PR 단위로 커밋을 관리하는 방법이 없을까 찾다가 Squash and Merge 기능이 있다는 것을 알았다. Rebase and Merge 방식도 있는데 알아보도록하자!

Merge 방식 종류

PR의 Merge 버튼을 살펴보면,

• Create a merge commit
• Squash and merge
• Rebase and merge

세 가지가 있다.

Create a merge commit

feature 브랜치에서 develop 브랜치로 Create a merge commit 방식을 사용하여 머지한다면,
develop 브랜치의 커밋 히스토리는 A-1-2, A-1-2 모두 남게된다. 또한 merge commit A-2가 새롭게 추가된다.

Squash and merge

feature 브랜치에서 develop 브랜치로 Squash and merge 방식을 사용하여 머지한다면,
develop 브랜치의 커밋 히스토리는 A-1-1, A-1-2는 생략되고 A-1, A-2 두개만 남게된다.

커밋 메시지는 Github 설정에서 PR 의 title로 설정할 수도 있다.

하지만 develop 에서 main으로 merge 할 때도 Squash and merge 방식을 사용한다면, A-1, A-2 커밋도 생략되어 버린다.
main 으로 merge 할 때는 다른 방식을 사용하는게 좋다 생각했다.

Rebase and merge

Rebase and merge를 알기전에 rebase와 fast-forward가 뭔지 알아보자.

fast-forward

fast-forward 상태를 판별하려면, 분기한 브랜치의 커밋 히스토리가 기존 브랜치의 커밋 히스토리를 포함하고 있는가를 생각하면된다.

feature2-2 커밋은 develop2의 커밋 히스토리를 포함하지 않기 때문에 fast-forward 상태가 아니다.
rebase를 수행한다면, fast-forward 상태로 만들 수도 있다.

rebase

feature1-2와 feature2-2 커밋의 base는 develop1이다.

base는 해당 브랜치가 파생된 브랜치를 가리킨다.
rebase는 base를 바꾸는 작업이다.

Rebase and merge

rebase and merge 방식은, base 브랜치를 최신 브랜치로 재설정하고 fast-forward 상태에서 머지를하는 방식이다.

Create a merge commit 과는 다르게 merge commit이 남지않는다.
하지만 feature 브랜치의 커밋이 모두 남게된다.
develop 보다는 main으로 머지할때 적합한 방식인것 같다고 생각했다.
써보니.. 커밋 해시가 달라져서 develop에서 main으로 머지할때는 Create a merge commit 방식이 적합한 것 같다