[git] branch merge 방법과 특징

 

git의 branch란?

git은 데이터를 change set이나 변경사항(diff)으로 기록하지 않고, 일련의 스냅샷으로 기록한다.

커밋을 하면 git은 현 staging area에 있는 데이터의 스냅샷에 대한 포인터, 저자나 커밋 메세지 같은 메타데이터, 이전 커밋에 대한 포인터 등을 포함하는 커밋 개체를 저장한다. 이전 커밋 포인터가 있어서 현재 커밋이 무엇을 기준으로 바뀌었는지 알 수 있다. 최초 커밋을 제외한 나머지 커밋은 이전 커밋 포인터가 적어도 하나씩 있고, 브랜치를 합친 merge 커밋의 경우 이전 커밋 포인터가 여러 개 있다.

git의 브랜치는 커밋 사이를 가볍게 이동할 수 있는 어떤 포인터 같은 것이라고 생각하면 된다. 기본적으로 git은 main(과거엔 master) 브랜치를 만든다. 처음 커밋하면 이 main 브랜치가 생성된 커밋을 가리킨다. 이후 커밋을 만들면 main 브랜치는 자동으로 가장 마지막 커밋을 가리킨다.

 

git branch merge 방법과 특징

1. Merge Commit을 만들며 합치기

두 브랜치의 변경사항을 모두 유지하면서 병합하는 방식. 이 방식을 사용하면 각 브랜치의 변경사항이 과거의 커밋으로 보존되고, 새로운 커밋이 추가되어 최종 병합이 완료된다.

ⓒcodeit

• 장점: 브랜치의 히스토리를 모두 유지하면서 변경사항 병합이 가능하기 때문에 프로젝트 진행 상황 파악 및 추적에 용이하다. 또한, 모든 커밋의 커밋 아이디가 바뀌지 않기 때문에 다음에 나올 두 방식에 비해 비교적 사용이 쉽다.
• 단점: 다양한 브랜치에서 여러 작업이 이루어지면 커밋 히스토리가 복잡해질 수 있다.

 

2. Squash and Merge

브랜치에서의 모든 변경 사항을 하나의 커밋으로 압축하여 병합하는 방식. 이 방식은 각 커밋에서 발생한 모든 변경 사항을 병합 후에 하나의 새로운 커밋을 생성한다.

ⓒcodeit

• 장점: 커밋 히스토리를 간단하게 유지할 수 있다. 각 커밋이 특정 Pull Request를 대변하고, 하나하나가 완성된 기능을 의미하기 때문에 의미 파악이 빠르다. 주요한 사항을 압축적으로 담는다.
• 단점: 압축되기 때문에 상세한 작업 이력을 잃는다. 각 커밋별 개별 맥락이나 작업자 정보가 포함되지 않아 추후 문제 해결에 어려움이 생길 수 있다. 또한 기존 커밋 아이디가 합쳐지면서 새로운 커밋 아이디가 생성되어 여러 명이 해당 브랜치를 기반으로 작업을 하고 있었다면 복잡해진다.
  (GitHub에는 모든 커밋 기록들이 남기 때문에 작업 이력이 아예 사라지는 것은 아니고, Pull Request를 검색해서 히스토리 확인은 가능하다)

 

3. Rebase and Merge

현재 브랜치를 타겟 브랜치에 재위치(rebase)시킨 후 병합하는 방식. 이 방식은 타겟 브랜치의 커밋 위로 현재 브랜치의 모든 커밋을 옮겨 놓는 것과 같다. 히스토리는 선형적으로 유지된다.

ⓒcodeit

• 장점: 깨끗하고 선형적인 커밋 히스토리를 만들어 준다. 히스토리 파악 및 코드의 변화 이해가 쉽다.
• 단점: 관련 커밋 아이디가 모두 바뀌게 되어 혼란을 초래할 수 있음. 특히 브랜치가 크게 분기된 경우 복잡하고, 여러 개발자가 동시에 작업을 수행한 경우 복잡한 충돌을 일으킬 수 있다. 또한, PR별로 다른 기능으로 나뉜 작업 이력이 하나로 합쳐져 구분하여 파악하기 어려워진다.

 

각 방법에 따른 장단점이 다르기 때문에, 기본적으로 머지 커밋 방식으로 진행하되 프로젝트 규모가 커져서 머지 커밋만으로 관리가 어려워지면, 목적에 따라 squash나 rebase 방식을 활용하는 방법을 적용하면 된다.