브랜치 병합 — 정의, 병합 전략 및 충돌 해결

Git에서 머지란

Git에서 머지는 두 개 이상의 개발 기록을 하나로 결합하는 작업입니다. 개발자가 브랜치를 병합하면 Git은 자동으로 공통 조상(베이스 커밋)을 찾고 두 브랜치의 변경 사항을 포함하는 새로운 머지 커밋을 생성합니다. Three-way merge는 공통 조상, 첫 번째 브랜치, 두 번째 브랜치의 세 가지 상태를 비교하는 표준 알고리즘입니다.

머지 프로세스는 git merge 명령으로 시작됩니다. Git은 브랜치가 분기된 지점을 확인하고 소스 브랜치에서 대상 브랜치로 변경 사항을 순차적으로 적용합니다. 변경 사항이 충돌하지 않으면 Git은 설정에 따라 fast-forward를 수행하거나 머지 커밋을 생성합니다. Fast-forward는 대상 브랜치가 소스 브랜치의 커밋으로 단순히 이동하는 시나리오입니다.

# 대상 브랜치로 전환하여 병합
git checkout main
git merge feature/payment-module

# 명시적 no-fast-forward로 병합
git merge --no-ff feature/payment-module

# 충돌이 너무 복잡하면 병합 중단
git merge --abort

--no-ff 플래그(no fast-forward)는 fast-forward가 가능한 경우에도 머지 커밋 생성을 강제합니다. 이는 변경 사항이 별도의 브랜치에서 이루어졌다는 정보를 보존합니다. 많은 팀이 브랜칭 기록을 명시적으로 유지하기 위해 이 방식을 선호합니다.

브랜치 병합 방법

Git에는 세 가지 주요 브랜치 병합 전략이 있으며, 각각 특정 시나리오에 적합합니다. 전략 선택은 팀 문화와 프로젝트 기록의 명확성 요구 사항에 따라 달라집니다.

Standard merge는 두 개의 부모를 가진 머지 커밋을 생성합니다. 전체 기록은 보존되지만 브랜칭 그래프는 더 복잡해집니다. Squash merge는 피처 브랜치의 모든 커밋을 하나로 결합하여 대상 브랜치 위에 적용합니다. 기록은 선형적이고 깔끔해지지만 중간 단계에 대한 정보는 손실됩니다.

Rebase는 완전한 머지는 아니지만 동일한 결과를 얻습니다. 한 브랜치의 변경 사항이 다른 브랜치 위로 이동됩니다. 차이점은 기록이 다시 쓰여진다는 것입니다. 피처 브랜치의 커밋은 대상 브랜치의 최신 커밋 위에 다시 생성됩니다. 이는 완벽하게 선형적인 기록을 제공하지만 푸시 시 force push가 필요합니다.

머지 충돌 해결 방법

머지 충돌은 파일의 동일한 줄이 두 브랜치에서 변경될 때 발생합니다. Git은 자동으로 어떤 버전을 유지할지 결정할 수 없으며 개발자의 개입이 필요합니다. 충돌은 <<<<<<<, =======, >>>>>>> 특수 마커를 사용하여 파일에 표시됩니다.

충돌 해결 프로세스는 여러 단계로 구성됩니다. 먼저 개발자는 충돌하는 파일을 열고 필요한 변경 사항을 수동으로 선택합니다. 단순히 하나의 버전을 선택하는 것이 아니라 두 변경 사항의 로직을 이해하고 올바른 결정을 내리는 것이 중요합니다. 파일을 편집한 후 충돌 마커를 제거하고 git add를 통해 스테이징 영역에 추가합니다.

# 충돌 파일 목록 보기
git status

# mergetool 시작 (예: VS Code, IntelliJ)
git mergetool

# 모든 충돌 해결 후
git add .
git merge --continue

# 또는 병합을 완전히 중단
git merge --abort

시각적 머지 도구를 사용하면 충돌 해결 속도가 크게 빨라집니다. VS Code, IntelliJ IDEA 및 GitKraken은 현재 브랜치, 들어오는 브랜치, 결과의 세 가지 패널이 있는 인터페이스를 제공합니다. git mergetool 도구는 충돌하는 각 파일에 대해 설정된 편집기를 자동으로 엽니다.

복잡한 충돌을 피하는 가장 좋은 방법은 피처 브랜치를 메인 브랜치와 정기적으로 동기화하는 것입니다. 개발자가 하루에 한 번 main을 자신의 브랜치에 병합하면 충돌이 작고 쉽게 해결할 수 있습니다. 일주일 동안 변경 사항을 축적하면 오류 위험이 높은 복잡한 충돌이 발생합니다.

merge 대신 rebase를 사용해야 하는 경우

Rebase와 merge는 변경 사항을 결합하는 두 가지 방법이며, 둘 사이의 선택은 종종 팀 내에서 논란을 불러일으킵니다. Rebase는 기록을 다시 쓰면서 한 브랜치의 커밋을 다른 브랜치 위로 이동합니다. Merge는 브랜칭 기록을 보존하면서 새로운 머지 커밋을 생성합니다. 각 접근 방식에는 장점과 제한 사항이 있습니다.

Rebase는 개발자가 로컬 피처 브랜치에서 작업 중이고 Pull Request를 생성하기 전에 깔끔한 선형 기록을 원할 때 적합합니다. Rebase 후 모든 커밋은 불필요한 머지 커밋 없이 순차적으로 정렬됩니다. 그러나 rebase에는 force push가 필요하며 여러 사람이 동시에 작업하는 브랜치에는 적용할 수 없습니다.

• Rebase — 깔끔한 기록이 필요한 개인 피처 브랜치용
• Merge — 공유 브랜치 및 병합 시점 기록용
• Squash — 피처 브랜치에 작은 드래프트 커밋이 많을 때

Git의 황금률: 이미 공유 리포지토리에 푸시된 커밋에는 rebase를 사용하지 마세요. 이렇게 하면 공유 브랜치의 기록이 변경되지 않고 다른 개발자가 중복되거나 손실된 커밋을 만나지 않게 됩니다. 피처 브랜치를 메인 브랜치에 통합하려면 Pull Request를 통한 merge를 사용하세요.

브랜치 병합 모범 사례

올바른 머지 프로세스는 안정적인 개발의 기초입니다. 현대 팀 작업에서 머지는 콘솔을 통하지 않고 GitHub의 Pull Request 또는 GitLab의 Merge Request를 통해 수행됩니다. PR은 코드 리뷰, 자동 CI 검사를 거친 후에만 메인 브랜치에 병합됩니다.

첫 번째 모범 사례 — 모든 검사를 통과한 후에만 병합합니다. CI 파이프라인은 프로젝트를 빌드하고, 테스트를 실행하고, 코드 품질을 확인해야 합니다. 하나라도 검사에 실패하면 병합이 차단됩니다. 최신 플랫폼(GitHub, GitLab)에는 내장 보호 기능이 있습니다. 브랜치 보호 규칙은 CI 실패 시 자동으로 병합을 차단합니다.

두 번째 모범 사례 — 깨진 코드를 절대 병합하지 않습니다. 병합 전에 개발자는 자신의 변경 사항이 빌드를 깨뜨리거나 기존 기능을 회귀시키지 않는지 확인해야 합니다. 이를 위해 자동화된 테스트와 코드 리뷰가 있습니다.

세 번째 모범 사례 — 병합 후 피처 브랜치를 정리합니다. 이미 병합된 브랜치는 삭제해야 합니다. 이는 혼란과 리포지토리의 난잡함을 방지합니다. GitHub는 PR 병합 후 자동으로 브랜치 삭제를 제안하며, 리포지토리 설정을 자동 삭제로 구성할 수 있습니다.