[Git] 여러가지 merge 전략

Jessie·2024년 1월 30일

Merge(머지)란 분기했던 브랜치에서 작업한 것을 다시 메인 브랜치로 합치는 작업을 말한다.
머지를 하게 되면 commit history가 남게 되는데, commit에는 코드 변경 사항에 대한 기록이 남기 때문에 중요하다.
머지를 하는 방식에는 몇가지가 있다. 이 각각의 방식은 머지가 됐을 때 다른 방식으로 commit history를 남기므로 프로젝트를 진행할때 어떤 방식으로 머지를 진행할 것인지 생각해보면 좋을 것 같다.


1. Fast-Forward Merge

기존 브랜치로부터 어떤 브랜치가 분기해 나간 뒤 메인 브랜치에 아무런 변경 사항이 없을 수 있다. 이때 분기한 브랜치는 기존 브랜치의 모든 커밋 히스토리를 가지고 있다. 이 두 브랜치의 관계를 fast-forward 관계라고 한다.

Fast-forward 관계에 있는 두 브랜치를 머지하면 단순히 기존 브랜치에 분기한 브랜치의 커밋들이 쌓이는 형식이 된다.

만약 브랜치가 분기해 나간 뒤 기존 브랜치에 커밋 히스토리가 쌓이면, 분기한 브랜치에 포함되지 않은 기존 브랜치 커밋 히스토리가 있으므로 fast-forward 관계가 아니다.

2. Merge Commit

머지 커밋은 기존 브랜치의 커밋 히스토리와 분기한 브랜치의 커밋 히스토리를 시간 순서대로 합친 후, 마지막에 머지 커밋을 하나 더 추가한다.

그러면 아래와 같은 형태가 된다.

머지 커밋에는 머지가 언제 발생했는지, 어디 브랜치에서 발생했는지 등 머지에 대한 정보를 담고있다. 따라서 모든 커밋 기록과 머지 커밋이 남아 코드의 변경사항을 상세하게 파악할 수 있다. 다만 매우 사소한 커밋까지도 전부 기록이 남기 때문에 커밋이 쌓일수록 히스토리를 추적하기 어려워질 수 있다.

3. Squash Merge

스쿼지 머지는 머지를 진행할 때 분기한 브랜치의 커밋들을 하나의 커밋으로 합친 후 기존 브랜치에 머지하는 것을 말한다. 이때 합쳐진 커밋들은 머지 커밋 기록으로 남게 된다.

스쿼시 머지를 하면 언제 어떻게 머지가 되었는지, 해당 머지가 일어났을 때 브랜치에서 어떤 변경사항이 일어났는지 알 수 있다. 커밋 히스토리가 전부 합쳐지기 때문에 커밋 히스토리를 깔끔하게 유지할 수 있지만, 브랜치의 변경 내역을 상세하게 알수는 없다.

4. Rebase Merge

리베이스 머지는 베이스를 바꾸어 머지하는 것을 말한다. 쉽게 말하자면 분기된 브랜치의 커밋 히스토리를 시간과 상관없이 기존 브랜치의 가장 마지막 커밋 뒤로 붙이는 것이다.

아래 그림을 보면 Feature 브랜치는 Main 브랜치의 A2 커밋 이후 분기되었다. Main 브랜치에는 C1, C2 커밋이 쌓였고, Feature 브랜치에도 B1, B2 커밋이 쌓였다. 이때 Feature 브랜치의 원래 베이스는 A2 커밋이었지만, 베이스를 Main 브랜치의 가장 마지막 커밋인 C2 커밋으로 바꿔 그 뒤로 커밋 히스토리를 붙이는 것이다.

리베이스 머지는 커밋 히스토리가 전부 남아있어 코드의 변경사항을 자세히 파악할 수 있지만, 머지 커밋이 남지 않아 언제 머지가 진행되었는지 알기 힘들다.

머지를 진행할 때 두 커밋 사이에 같은 라인의 코드가 서로 다르게 변경되어있다면 충돌이 일어나게 된다. 특히 리베이스 머지의 경우 커밋을 하나씩 쌓을때마다 충돌이 발생한 부분을 해결해야 하기 때문에 계속해서 충돌이 일어나는 것 처럼 보일 수 있다.

프로젝트를 진행하면서 리베이스 머지를 진행할때마다 충돌이 끝없이 일어나서 멘붕이 왔었던 기억이 있다. 하지만 이미 일어났다면.. 해결할수밖에...


참고자료

profile
주니어 프론트엔드 개발자입니다 😎

0개의 댓글