머지 — 정의, 병합 유형 및 작동 메커니즘

머지란?

머지(병합)는 Git의 기본 작업으로, 한 브랜치(소스)에서 다른 브랜치(대상)로 변경 사항을 통합합니다. 병합 결과, 대상 브랜치는 소스 브랜치에 아직 없었던 모든 커밋을 받습니다. 상황에 따라 Git은 세 가지 다른 방식으로 머지를 수행할 수 있습니다.

머지의 주요 가치는 기록 보존입니다: 병합 커밋은 브랜치 병합 사실을 기록하고, 언제 어떤 브랜치가 병합되었는지에 대한 정보를 보존합니다. 이는 변경 감사, 회귀 검색 및 개발 연대기 이해를 용이하게 합니다. 대규모 프로젝트에서 병합 커밋은 코드 통합의 표준 방식입니다.

GitLab Flow에 따르면, Git으로 작업하는 팀의 73%가 병합 커밋을 사용합니다. 대안적 접근 방식(리베이스, 스쿼시)은 선형 기록에 중점을 둔 팀이 선호합니다. 전략 선택은 팀 규모, 릴리스 빈도 및 프로젝트에서 수용된 규칙에 따라 달라집니다.

머지가 필요한 경우

머지는 개발자가 기능 작업을 완료하고 develop 또는 main에 통합하려는 경우 필요합니다. 일반적인 시나리오: 개발자가 develop에서 기능 브랜치를 만들고, 며칠 동안 작업했으며, 그동안 develop에 다른 팀원의 새 커밋이 추가되었습니다. 병합 전에 변경 사항을 결합해야 하며, 이를 위해 머지가 사용됩니다.

머지 없이 Git에서 단일 코드베이스로 협업하는 것은 불가능합니다. 두 개발자가 동시에 하나의 코드베이스를 변경할 때마다 브랜치가 분기됩니다. 머지는 데이터 손실 없이 이러한 변경 사항을 다시 통합하는 유일한 방법입니다.

Git의 병합 유형

Git은 세 가지 머지 유형을 지원하며, 각각 고유한 시나리오에 맞게 설계되었습니다. 머지 유형 선택은 커밋 기록, 롤백 편의성 및 로그 가독성에 영향을 미칩니다.

Fast-forward 머지

Fast-forward는 대상 브랜치에 소스 브랜치 생성 이후 새 커밋이 없을 때 발생합니다. 이 경우 Git은 단순히 대상 브랜치 포인터를 소스 브랜치의 마지막 커밋으로 앞으로 이동시킵니다. 기록은 선형으로 유지되며, 병합 커밋이 없습니다.

# Fast-forward 머지: 기능 생성 이후 develop 변경 없음
git checkout develop
git merge feature/new-login

# 결과: develop 포인터가 기능 끝으로 이동
# 병합 커밋이 생성되지 않음

Fast-forward는 개발자가 혼자 작업한 단기 브랜치에 편리합니다. 그러나 이 접근 방식에는 단점이 있습니다: 브랜치가 존재했다는 정보가 손실되어 모든 커밋이 develop에 직접 수행된 것처럼 보입니다.

Three-way 머지

Three-way 머지는 분기 지점 이후 두 브랜치 모두에 새 커밋이 있을 때 실행됩니다. Git은 두 부모를 가진 별도의 병합 커밋을 생성하여 브랜치 병합 사실을 기록합니다. 이 접근 방식은 팀 개발에서 기능 브랜치에 권장됩니다.

# --no-ff 플래그로 강제 three-way 머지
git checkout develop
git merge --no-ff feature/new-login

# 기본 메시지로 병합 커밋 생성됨
# -m으로 사용자 지정 메시지 설정 가능
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

--no-ff 플래그는 fast-forward가 가능한 경우에도 병합 커밋 생성을 보장합니다. 이는 프로젝트에서 브랜치 정보를 보존하기 위한 모범 사례입니다.

Squash 머지

Squash 머지는 소스 브랜치의 모든 커밋을 하나로 압축하여 대상에 적용합니다. 기능 기록이 손실되어 모든 변경 사항이 포함된 단일 커밋이 브랜치에 들어옵니다. 이는 기능 브랜치의 상세 커밋이 전체 기록에 가치를 더하지 않을 때 편리합니다.

# Squash 머지: 기능의 모든 커밋이 하나로 압축
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash는 초안, 실험적 브랜치 및 깔끔한 기록 유지가 중요한 상황에 적합합니다. 단점은 원래 커밋과의 연결이 손실되어 개별 변경 사항을 롤백하기 어렵게 만든다는 점입니다.

Ours 및 Theirs 전략

Ours와 Theirs는 Git의 두 가지 특별한 머지 전략입니다. Ours는 소스 브랜치의 변경 사항을 완전히 무시하고 대상에 있는 것만 유지합니다. Theirs는 반대로 충돌 시 소스 브랜치 버전을 수락합니다. 이러한 전략은 어떤 버전이 우선해야 하는지 미리 알려진 경우 대량의 코드를 병합할 때 유용합니다.

머지 작동 방식

Git의 머지 메커니즘은 세 지점의 비교를 기반으로 합니다: 공통 조상(머지 베이스), 소스 브랜치의 상태, 대상 브랜치의 상태. Git은 머지 베이스(두 브랜치에 공통된 마지막 커밋)를 찾고 분기 후 각 브랜치에서 어떤 변경이 발생했는지 계산합니다.

• 1단계 — Git이 머지 베이스 결정: 두 브랜치에 모두 존재하는 마지막 커밋
• 2단계 — Git이 두 개의 diff 생성: 머지 베이스에서 소스까지, 머지 베이스에서 대상까지
• 3단계 — Git이 두 변경 세트를 머지 베이스에 적용 시도
• 4단계 — 변경 사항이 충돌하지 않으면 머지 자동 완료
• 5단계 — 충돌이 있으면 Git이 중단하고 해결 요청

Git은 삼자 병합 알고리즘을 사용하여 비교하는 두 파일 버전뿐만 아니라 공통 조상도 고려합니다. 덕분에 Git은 한 브랜치의 변경이 다른 브랜치의 수정된 영역에 영향을 주지 않는 경우 — 두 파일이 모두 수정되었더라도 — 자동으로 해결할 수 있습니다.

머지 작동 예시

시나리오를 생각해보겠습니다: 두 개발자가 하나의 기능 브랜치에서 서로 다른 파일을 작업하고 있습니다. 첫 번째 개발자는 LoginActivity.kt를 변경했고, 두 번째 개발자는 ProfileFragment.kt를 변경했습니다. 변경 사항을 병합할 때 Git은 변경 사항이 다른 파일에 영향을 미쳤음을 확인하고 인간의 개입 없이 자동으로 머지를 수행합니다.

두 개발자가 모두 LoginActivity.kt를 변경했지만 다른 메서드에서 변경한 경우 — Git도 자동으로 처리하여 변경 사항을 라인별로 병합합니다. 충돌은 두 개발자가 동일한 라인을 변경했거나 한 명이 다른 사람이 변경한 코드를 삭제한 경우에만 발생합니다.

머지 충돌 해결

머지 충돌은 두 브랜치가 동일한 라인을 다르게 수정하여 Git이 자동으로 변경 사항을 병합할 수 없을 때 발생합니다. 이 경우 Git은 파일에서 충돌 영역을 표시하고 개발자의 수동 해결을 기다립니다.

충돌 영역은 특수 마커로 표시됩니다: <<<<<<< HEAD는 대상 브랜치의 코드, =======는 구분자, >>>>>>> source-branch는 소스 브랜치의 코드를 보여줍니다. 개발자는 수동으로 어떤 버전을 유지할지 또는 결합할지 선택해야 합니다.

# 1. 머지 실행 및 충돌 확인
git merge feature/new-login
# 출력: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. 충돌이 있는 파일 목록 보기
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. 충돌 해결: 파일 편집, 마커 제거
# 4. 해결된 파일 추가 및 머지 완료
git add src/ui/login/LoginActivity.kt
git merge --continue
# 또는: git commit(--continue 없이)

충돌 해결을 위한 도구가 있습니다: git mergetool은 시각적 병합 도구(Meld, Beyond Compare, VS Code)를 엽니다. 많은 개발자가 IDE에서 충돌을 해결하는 것을 선호합니다 — IntelliJ IDEA와 Android Studio는 이 과정을 크게 간소화하는 3패널 비교가 내장된 도구를 제공합니다.

충돌 해결 팁: 충돌의 각 측면이 무엇을 하는지 항상 이해하고, 로직을 이해하지 않고 타인의 코드를 삭제하지 말며, 충돌이 너무 복잡하면 두 브랜치 작성자를 공동 해결에 참여시키십시오.

머지 vs 리베이스: 언제 무엇을 선택할까

머지와 리베이스의 선택은 Git에서 가장 일반적인 아키텍처 결정 중 하나입니다. 두 접근 방식 모두 변경 사항을 결합하지만, 방식이 다릅니다: 머지는 브랜치 기록을 보존하고, 리베이스는 기록을 다시 작성하여 선형으로 만듭니다.

• 머지 — 컨텍스트 보존: 언제 어떤 브랜치에서 병합되었는지 확인 가능. 공개 브랜치(develop, main) 및 팀 작업에 적합
• 리베이스 — 추가 병합 커밋 없이 깔끔한 선형 기록 생성. 검토 전 개인 기능 브랜치에 적합
• 규칙: 다른 개발자가 사용 중인 공개 브랜치는 절대 리베이스하지 마십시오

많은 팀이 하이브리드 접근 방식을 사용합니다: 기능 브랜치를 develop으로 업데이트하기 위해 리베이스(git rebase develop)하고, 병합을 기록하기 위해 --no-ff 플래그로 머지합니다. 이는 기능 내에서 깔끔한 기록과 develop 수준에서 정보성 있는 병합 지점을 제공합니다.