Git branch 정리 관련(PR)

PR을 올리고 approved가 끝나면 담당자는 merge를 하게 되는 merge 방식에는 3가지가 존재한다.

1. Create a mege commit

• 기본값으로 선택되어 있는 merge 방식

• feature 브랜치가 root 브랜치로 합쳐지는 기본적인 머지 방식

2. Squash and merge

• feature 브랜치에 커밋 된 여러 개의 변경사항을 1개의 커밋으로 압축하여 root브랜치에 추가하는 방식

• Squash and merge 를 사용하게 되면 위와 같은 커밋 이력들을

• 하나의 커밋 이력으로 압축할 수 있다.

3. Rebase and merge

• feautre 브랜치에 커밋된 여러 개의 변경사항을 root브랜치의 최상단에 끼워 넣는 방식

• 위와 같은 상황에서 Rebase and merge 를 하게되면

• commit 이력들이 root 브랜치에 추가되게 됨

어떻게 사용할까?

• feature 브랜치에서는 자유롭게 커밋하고 사용하되, root에 merge 할 때는 커밋 단위를 의미가 있는 범위로 나누거나 합쳐서 올리자!

서스테이닝 및 가벼운 일감인 경우 > Squash and merge 방식 사용

• 간단한 일감이라도 개발하고 테스트하다보면 수정사항 발생
• 동일한 파일에 대해 여러 번 변경을 하는 경우도 있고, 코드 리뷰에서 나온 피드백을 반영하면서 자잘한 수정사항이 계속 생길 수 밖에 없음
• 일반 merge를 하는 경우 자잘한 수정 이력이 모두 root 브랜치에 남기 때문에 다수가 개발할 경우 복잡도가 증가함
• Squash and merge 방식을 사용하여 커밋 깔끔하게 커밋 메시지를 압축하자

다소 큰 일감인 경우 > Rebase and merge 방식 사용

• 큰 일감의 경우 squash 방식을 사용하면 너무 많은 변경사항이 압축되므로 오히려 이력 추적이 어려울 수 잇음
• 커밋 단위를 기능 위주로 쪼개서 여러 번 커밋하고, Rebase and merge 방식으로 merge하여 변경 이력을 넣어주는게 좋음
• rebase 방식은 커밋 단위 각각이 root 브랜치의 커밋 단위가 되기 때문에 커밋 메시지를 좀 더 직관적이고 깔끔하게 작성해주는게 좋음

에픽 일감 브랜치와 root 브랜치의 병합인 경우 > Create a merge commit 방식 사용

• 에픽 일감 브랜치(예: dev-overseas, dev-korail)는 매우 큰 과제이며 장기간 개발이 필요한 경우 사용한다
• 때문에 에픽 브랜치에서 몇 개월에 걸쳐 작업을 하기 때문에 root 브랜치라고 볼 수 있음
• 따라서 에픽 일감이 완료되면 Create a merge commit 방식으로 merge 하여 커밋 이력이 남도록 함

 

feat. 강훈이형