Git으로 프로젝트를 관리하다 보면, 결국 두 개 이상의 브랜치를 합쳐야 하는 순간이 옵니다. 이때 선택할 수 있는 병합 방법에는 대표적으로 Fast-Forward 병합과 3-Way 병합이 있습니다.
이름만 들어도 Fast-Forward는 '빠르게 앞으로 나아간다'는 느낌이고, 3-Way는 '복잡한 절차'처럼 들립니다.
😯 그렇다면, 정말 Fast-Forward 병합 방식이 3-Way 병합보다 빠를까요?
아니면, 단순히 이름 때문에 우리가 그렇게 생각하는 걸까요?
이번 글에서는 Fast-Forward와 3-Way 병합의 원리를 이해하고, 실제로 속도의 차이가 발생하는 이유를 알아보겠습니다.
또한, 상황에 따라 어떤 병합 방식이 더 적합한지 선택 기준도 함께 다뤄보겠습니다.
Fast-Forward 병합: 빠를 수 밖에 없는 이유
Fast-Forward 병합은 현재 브랜치에서 대상 브랜치까지의 경로가 직선으로 연결되어 있을 때 가능합니다.
작동 원리
Git은 실제로 병합을 수행하지 않고, 단순히 현재 브랜치의 포인터 이동만으로 대상 브랜치의 최신 커밋으로 이동시킵니다.
이렇게 하면 두 브랜치의 히스토리가 하나로 합쳐집니다.
결과
- 장점: 빠르고 효율적입니다.
- 단점: 병합 커밋이 없어 히스토리가 단순하지만, 변경 내역 추적이 어렵습니다.
Fast-Forward 병합은 단순히 포인터 레퍼런스를 업데이트하는 작업으로, 병합 시 Git이 추가로 처리해야 할 계산이 거의 없습니다. 이는 병합 과정에서의 연산 시간이 극도로 짧다는 것을 의미합니다.
3-Way 병합
3-Way 병합은 브랜치들이 서로 다른 변경 사항을 가지고 있어 Fast-Forward 병합이 불가능한 경우 즉, 두 브랜치가 서로 다른 히스토리를 가지고 있을 때 수행됩니다.
작동 원리
- 두 브랜치의 최신 커밋과 그들의 공통 조상(commit)을 비교합니다.
- 변경된 내역을 분석하고, 충돌이 있는 경우 이를 해결한 뒤 새로운 병합 커밋을 생성합니다.
이러한 3-Way 병합은 병합 커밋을 통해 두 브랜치의 히스토리를 하나로 통합합니다.
결과
- 장점: 병합 커밋으로 인해 변경 히스토리가 명확하게 남습니다.
- 단점: 비교와 충돌 해결 작업으로 인해 속도가 느려질 수 있습니다.
- Git은 최신 커밋과 공통 조상을 비교하고, 각각의 차이를 분석해야 합니다.
- 변경 충돌이 발생하면 이를 수동으로 해결하는 과정이 추가됩니다.
이러한 추가 작업은 Fast-Forward 병합보다 상대적으로 더 많은 시간과 연산을 요구합니다.
⚠️ 주의할 점
GitHub의 웹 인터페이스에서는 기본적으로 Fast-Forward 병합을 지원하지 않습니다.
- Pull Request를 통해 병합할 때, github는 3-Way 병합을 기본으로 사용합니다.
- 이는 협업 환경에서 변경 내역 추적과 히스토리 관리를 중요시하기 때문입니다.
- 그러나 로컬 환경에서 Fast-Forward 병합을 수행한 후 이를 원격 저장소에 푸시하면, GitHub는 해당 병합을 인식하고 관련된 Pull Request를 자동으로 닫습니다.
또한, GitHub의 'Rebase and merge' 옵션은 커밋 정보를 업데이트하고 새로운 커밋 해시를 생성하므로 실제 Fast-Forward 병합과는 차이가 있습니다.
따라서, Git에서의 병합 전략을 이해하고 상황에 맞게 적절한 방법을 선택하는 것이 중요합니다.
어떤 병합이 더 적합할까?
1. Fast-Forward 병합이 적합한 경우
- 히스토리가 단순하고, 병합 흔적이 필요 없는 상황
- 개인 프로젝트나 단일 브랜치 워크플로우에 적합
2. 3-Way 병합이 적합한 경우
- 협업 환경에서 변경 내역을 명확히 추적하고 싶을 때
- 충돌 가능성이 높거나, 팀원 간 작업 분리가 중요한 상황
그래서, 누가 더 빠를까?
속도만 놓고 보면 Fast-Forward 병합이 더 빠릅니다. 포인터 이동만으로 작업이 끝나기 때문이죠!
💡 그러나 속도보다 중요한 건 상황에 맞는 병합 방식을 선택하는 것입니다.
당신의 프로젝트에 필요한 병합 방식은 무엇인가요?
