브랜치를 어떤 방법으로 병합하는게 좋을까? (뉴스피드 프로젝트)

김상엽·2024년 2월 14일

Git

목록 보기

2/3

Github 협업 flow

우리는 프로젝트를 진행하면서 반드시 Github의 로그를 보게된다.

이상적인 Github 협업 flow는 다음과 같지만

우리의 Github 협업 flow는 엉망이었다.

어떻게 하면 이상적인 Github 협업 flow를 만들 수 있을까?

Merge 전략

Github에는 다양한 브랜치 병합 방법이 있다.
Merge, Squash & Merge, Rebase & Merge 의 방법을 알아보도록 하자

Merge

일반적으로 많이 사용되는 병합이며, 커밋 이력을 모두 남길 때 사용한다.
이 방식은 다시 Fast-Forward 방식과 Recursive 방식으로 나뉜다.

Merge (Fast-Forward)

새로운 브랜치 my-branch 가 main 브랜치로부터 분기된 이후,
main 브랜치에 새로운 커밋이 올라오지 않았다면,
my-branch 가 main 와 비교하여 최신의 브랜치라고 할 수 있다.
이런 경우 my-branch 의 변경 이력을 그대로 main 으로 가져올 수 있는데,
이를 Fast-Forward Merge 라고 한다.

Merge (Recursive)

my-branch 가 main 브랜치에서 분기되고, main 브랜치에 새로운 커밋이 생겼다면,
my-branch 를 최신이라고 간주할 수 없다.
따라서 my-branch 와 main 을 공통 부모로 한 새로운 Merge Commit 을 생성하게된다.
이런 방법을 Recursive Merge라고 한다.
Fast-Forward Merge가 가능한 상태에서 git merge 명령에 --no-ff 옵션을 주면 강제로 Merge Commit을 생성하게 할 수 있다.

Squash & Merge

Squash는 여러개의 커밋을 하나의 커밋으로 합치는 것을 의미한다.
Squash Merge는 병합할 브랜치의 모든 커밋을 하나의 커밋으로 Squash한 새로운 커밋을
Base 브랜치에 추가하는 방식으로 병합하는 것을 의미한다.
Squash를 하게 되면 모든 커밋 이력이 하나의 커밋으로 합쳐지며 사라진다는 점을 주의해야한다.

Rebase & Merge

Rebase를 알아보기 전에 Base가 무엇인지 알아보자.
my-branch 가 main 브랜치의 A 커밋에서 분기되었다고 하자.
이때, my-branch 의 Base는 A 커밋이다.
그렇다면, Rebase는 무엇일까? 말 그대로 Base를 다시 설정한다는 의미이다.
그럼 Base를 어디로 다시 설정할까? my-branch 가 분기된 main 브랜치의 최신 커밋이다.
Rebase를 하면 커밋들의 Base가 변경되므로 Commit Hash 또한 변경 될 수 있다.
이로 인해 Force Push를 해야할 경우도 있으니 주의하자.

참고한 글 : https://hudi.blog/git-merge-squash-rebase/

프로젝트에 적용

알아본 내용을 팀원들과 이해하고 익히기 위해 연습용 Github 저장소를 만들어 열심히 실험을 해보았다.

마침내 각 merge 방법들의 특징과 언제 사용하면 좋을지에 대한 결론에 도달하였다.

기능별 브랜치 -> dev 브랜치

Squash & Merge (하나의 기능에 대한 커밋을 묶어서 볼 수 있다)

dev 브랜치 -> master 브랜치

Rebase & Merge (병합시 병합된 내용을 한눈에 볼 수 있다)