Conflict Resolution

Conflict Resolution

Git 충돌 해결 (Conflict Resolution) 은 협업 개발 과정에서 발생하는 코드 충돌을 식별하고 해결하는 프로세스로, 3-way merge 알고리즘을 기반으로 한다. 여러 개발자가 동일한 파일의 동일한 부분을 수정할 때 발생하는 충돌을 식별하고, 해결하는 전략과 도구, 워크플로우를 포함한다. 주요 단계는 충돌 탐지 → 수동/자동 해결 → 검증으로 구성되며, 최근 AI 기반 자동화 도구들이 주목받고 있다.

핵심 개념

Git 충돌 해결 (Conflict Resolution) 은 두 개 이상의 개발자가 동일한 파일의 동일한 부분을 수정할 때 발생하는 충돌을 식별하고 해결하는 과정이다. 충돌은 Git 이 변경사항을 자동으로 병합할 수 없을 때 발생하며, 개발자가 수동으로 어떤 변경사항을 유지할지 결정해야 한다.

목적 & 필요성

• 목적: Git 충돌 해결의 주요 목적은 서로 다른 브랜치를 결합하고 충돌하는 수정사항을 해결하는 것이다. 이를 통해 코드 무결성을 유지하고, 여러 개발자의 작업을 통합하며, 프로젝트 진행이 원활하게 이루어지도록 한다.
• 필요성: 충돌 해결은 협업 개발의 필수적인 부분이다. 충돌은 개발 과정에서 피할 수 없는 현상으로, 이를 효과적으로 해결하는 능력은 개발자에게 필수적인 기술이다. 충돌을 제대로 해결하지 않으면 코드 손실, 기능 손상, 개발 지연 등의 문제가 발생할 수 있다.

주요 기능 및 특징

주요 기능

1. 충돌 식별: Git 은 자동으로 충돌이 발생한 파일과 위치를 식별하고 표시한다.
2. 충돌 마커 생성: 충돌 발생 시 Git 은 충돌 영역을 명확히 구분하는 마커를 추가한다.
3. 해결 도구 지원: Git 은 충돌 해결을 위한 다양한 명령어와 도구를 제공한다.
4. 선택적 전략 적용: 다양한 병합 전략과 옵션을 제공하여 상황에 맞는 충돌 해결 방식을 선택할 수 있다.

특징

1. 명시적 해결 요구: 충돌이 발생하면 Git 은 자동으로 병합하지 않고, 사용자가 명시적으로 해결하도록 요구.
2. 마커 기반 표시: 충돌 발생 시 <<<<<<< HEAD, =======, >>>>>>> branch 같은 마커로 충돌 영역을 명확히 표시
3. 다양한 해결 전략: -X ours, -X theirs 등 다양한 병합 전략 제공
4. 도구 통합: 다양한 병합 도구와의 통합을 통한 시각적 충돌 해결 지원
5. 단계적 프로세스: 충돌 식별부터 해결, 커밋까지 체계적인 프로세스 제공

핵심 원칙 및 작동 원리

핵심 원칙

1. 3- 방향 병합 (Three-way Merge): Git 은 기본적으로 공통 조상 커밋과 두 브랜치의 최신 상태를 비교하는 3- 방향 병합 알고리즘을 사용한다.
2. 원자적 작업 (Atomic Operations): 병합 작업은 원자적으로 이루어져야 하며, 부분적인 병합 상태는 피해야 한다.
3. 개발자 의도 존중: 충돌 해결 과정에서 원래 개발자의 의도를 최대한 존중해야 한다.
4. 코드 무결성 유지: 충돌 해결 결과는 코드의 논리적 무결성을 해치지 않아야 한다.

작동 원리

Git 충돌 해결의 작동 원리는 다음과 같다:

1. 충돌 감지: Git 은 병합 과정에서 같은 파일의 같은 부분이 다르게 수정된 경우 충돌을 감지한다.
2. 충돌 마킹: 충돌이 발생한 파일에 충돌 영역을 표시하는 마커를 삽입한다.
3. 병합 중단: Git 은 자동 병합 과정을 중단하고 사용자에게 충돌 해결을 요청한다.
4. 해결 과정: 개발자는 충돌 파일을 수정하여 최종 상태를 결정한다.
5. 해결 완료 표시: 충돌이 해결된 파일을 스테이징 (git add) 하여 해결 완료를 표시한다.
6. 병합 완료: 모든 충돌이 해결된 후 병합 작업을 완료 (git commit) 한다.

graph TD
    A[충돌 발생] --> B[Conflict Markers 삽입]
    B --> C[수동/자동 해결]
    C --> D[git add로 스테이징]
    D --> E[git commit 완료]

주요 원리 다이어그램

1
2
3

A---B---C (branch1)
    \
     D---E (branch2)

위 상황에서 병합 시 작동 원리:

1. 공통 조상 (B) 을 식별
2. branch1 의 변경사항 (B→C) 과 branch2 의 변경사항 (B→D→E) 을 비교
3. 충돌이 없는 부분은 자동 병합
4. 충돌이 발생한 부분은 마커로 표시하고 개발자의 개입 요청

구성 요소 및 아키텍처

구성 요소

1. 충돌 마커 시스템:
   • <<<<<<< HEAD: 현재 브랜치 (HEAD) 의 변경사항 시작
   • =======: 구분선
   • >>>>>>> branch: 병합하려는 브랜치의 변경사항 끝
2. 병합 전략 (Merge Strategy):
   • recursive: 기본 전략, 3- 방향 병합 알고리즘 사용
   • resolve: 2- 방향 병합에 사용
   • octopus: 2 개 이상 브랜치 병합에 사용
   • ours: 현재 브랜치 변경사항만 유지
   • subtree: 하위 프로젝트 병합에 사용
3. 전략 옵션 (Strategy Options):
   • ours: 충돌 시 현재 브랜치 변경사항 우선
   • theirs: 충돌 시 병합하려는 브랜치 변경사항 우선
   • patience: 더 신중한 병합 알고리즘 사용
   • ignore-space-change: 공백 변경 무시
4. 병합 도구 (Merge Tools):
   • git mergetool: 외부 병합 도구 통합 인터페이스
   • 다양한 외부 도구 (vimdiff, kdiff3, meld 등) 와 통합

아키텍처

Git 충돌 해결의 아키텍처는 다음과 같은 계층적 구조를 가진다:

1. Git 코어: 기본적인 병합 알고리즘과 충돌 감지 메커니즘
2. 병합 전략 레이어: 다양한 상황에 맞는 병합 전략 제공
3. 사용자 인터페이스 레이어: 충돌 표시 및 해결을 위한 인터페이스
4. 도구 통합 레이어: 외부 병합 도구와의 통합 지원

주요 병합 전략 요약 및 비교

Recursive (재귀적 병합)

• 기본 병합 전략으로, 3-way 병합 알고리즘을 사용한다.
• 두 브랜치의 공통 조상이 여러 개인 경우, 가상 커밋 (virtual commit) 을 만들어 이들을 먼저 병합한 뒤, 실제 병합을 진행한다.
• 이름 변경, 파일 이동 등 복잡한 변경 사항도 잘 처리한다.
• 대부분의 브랜치 병합에서 자동으로 사용된다.

Resolve (단순 병합)

• 3-way 병합이지만, 공통 조상이 하나일 때만 사용된다.
• 복잡한 충돌 상황을 잘 처리하지 못해, 최근에는 거의 사용되지 않는다.
• 예전 Git 버전에서 기본 전략이었으나, 현재는 recursive 로 대체되었다.

Octopus (문어발 병합)

• 두 개 이상의 브랜치를 한 번에 병합할 때 사용한다.
• 충돌이 없는 경우에만 동작하며, 충돌이 발생하면 병합이 중단된다.
• 대규모 프로젝트에서 여러 feature 브랜치를 동시에 병합할 때 유용하다.

Ours (현재 브랜치 우선)

• 병합 커밋만 생성하고, 실제 파일 내용은 현재 브랜치의 것만 남긴다.
• 상대 브랜치의 변경 사항은 모두 무시한다.
• 실험적 브랜치, 무시할 브랜치 병합 시 사용한다.

Subtree (하위 프로젝트 병합)

• 하위 디렉토리에 외부 프로젝트를 통합할 때 사용한다.
• 하위 프로젝트의 히스토리를 보존하면서 병합한다.
• 모노레포 (monorepo) 환경, 외부 라이브러리 통합 등에 활용된다.

장점과 단점

분류에 따른 종류 및 유형

실무 적용 예시

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

충돌 재현 및 해결 전략

Git 충돌 해결에서 ours 와 theirs 옵션은 충돌을 자동으로 해결하는 강력한 도구이다.
Git 에서 충돌은 Git 이 두 브랜치의 변경사항을 자동으로 결합할 수 없을 때 발생하며, 주로 같은 파일의 같은 부분이 서로 다르게 수정되었을 때 발생한다.

ours 전략

이 옵션은 충돌하는 부분을 현재 브랜치 (ours) 의 버전으로 자동 해결한다. 다른 트리의 변경사항 중 충돌하지 않는 부분은 병합 결과에 반영된다.

명령어:

1

git merge -X ours feature-branch

또는 파일 단위로:

1
2

git checkout --ours path/to/file
git add path/to/file

theirs 전략

‘ours’ 전략의 반대로, ’theirs’ 옵션은 충돌 해결 시 병합하는 브랜치의 변경사항을 우선한다.

명령어:

1

git merge -X theirs feature-branch

또는 파일 단위로:

1
2

git checkout --theirs path/to/file
git add path/to/file

주의사항

리베이스 중에 ‘ours’ 와 ’theirs’ 가 바뀔 수 있음을 주의해야 한다. 리베이스 시 ‘–ours’ 는 리베이스 대상 브랜치의 버전을, ‘–theirs’ 는 작업 중인 브랜치의 버전을 제공한다.

모든 충돌 파일에 대해 ‘–ours’ 또는 ‘–theirs’ 를 적용하려면 루트 디렉토리에서 git checkout --[ours/theirs]. 명령을 사용할 수 있다.

Rebase 충돌, Submodule 충돌 해결 절차

Rebase 충돌 해결

리베이스 중 충돌이 발생하면 다음 절차로 해결한다:

1. 충돌 확인: git status 로 충돌 파일 확인
2. 충돌 해결: 파일 수동 편집 또는 --ours/--theirs 옵션 사용
3. 해결 표시: git add <conflicted_files> 로 해결 표시
4. 리베이스 계속: git rebase --continue 로 리베이스 계속 진행
5. 필요시 건너뛰기: 필요한 경우 git rebase --skip 으로 현재 커밋 건너뛰기
6. 리베이스 중단: 문제 발생 시 git rebase --abort 로 리베이스 중단하고 원래 상태로 복귀

Submodule 충돌 해결

서브모듈 충돌은 다음과 같이 해결한다:

1. 충돌 식별: git status 로 충돌 서브모듈 확인
2. 서브모듈 디렉토리로 이동: cd <submodule_path>
3. 상태 확인: 서브모듈 디렉토리에서 git log 를 통해 충돌 원인이 되는 커밋 확인
4. 적절한 커밋 선택: 프로젝트 요구에 맞는 커밋 선택
5. 메인 프로젝트로 돌아와 변경사항 추가: 서브모듈 변경 후 메인 프로젝트 디렉토리로 돌아와 변경사항 추가
6. 테스트: 변경사항을 푸시하기 전에 프로젝트가 올바르게 작동하는지 테스트

서브모듈 충돌의 경우, 서브모듈 자체는 다른 저장소에 대한 참조만 포함하므로, 충돌 해결은 어떤 커밋을 참조할지 결정하는 것이 핵심이다.

충돌 발생 시 해결 프로세스

충돌 발생 시 체계적인 해결 프로세스는 다음과 같다:

1. 충돌 감지:
   • 병합/리베이스/풀 작업 중 Git 이 충돌 감지
   • git status 로 충돌 상태와 파일 확인
2. 충돌 파일 식별: git status 명령을 사용하여 충돌이 있는 파일 찾기
3. 충돌 분석:
   • 충돌 마커 (<<<<<<<, =======, >>>>>>>) 로 표시된 영역 확인
   • 양쪽 변경사항의 차이점과 의도 이해
4. 해결 전략 선택:
   • 수동 해결: 충돌 마커를 직접 편집하여 최종 상태 결정
   • 자동 해결: --ours, --theirs 등의 옵션 사용
   • 도구 활용: 병합 도구를 통한 시각적 해결
5. 충돌 해결:
   • 텍스트 편집기나 병합 도구로 충돌 파일 수정
   • 충돌 마커 제거 및 최종 코드 상태 결정
6. 해결 확인:
   • git add <file> 명령으로 해결된 파일 표시
   • 필요시 git diff --check 로 남은 충돌 마커 확인
7. 병합 완료:
   • 모든 충돌 해결 후 git commit 실행
   • 병합/리베이스 완료 메시지 확인
8. 테스트:
   • 충돌 해결 후 코드 정상 작동 테스트
   • 필요시 단위 테스트, 통합 테스트 실행

git mergetool 설정

git mergetool 은 외부 도구를 사용하여 충돌을 시각적으로 해결할 수 있게 도와준다.

기본 설정

git mergetool 을 호출하면 Git 은 $BASE(공통 조상), $LOCAL(현재 브랜치), $REMOTE(병합하려는 브랜치), $MERGED(결과 파일) 라는 임시 파일을 생성하여 도구에 전달한다.

기본 병합 도구 설정:

1

git config --global merge.tool <tool>

지원 도구 확인:

1

git mergetool --tool-help

도구별 설정

Vimdiff 설정

vimdiff 를 사용할 경우 Git 은 다음과 같은 4 창 레이아웃으로 Vim 을 연다:

• LOCAL: 현재 브랜치의 내용 (읽기 전용)
• BASE: 공통 조상의 내용 (읽기 전용)
• REMOTE: 병합하려는 브랜치의 내용 (읽기 전용)
• MERGED: 충돌 해결 결과를 작성할 파일 (쓰기 가능)

1
2

git config --global merge.tool vimdiff
git config --global mergetool.vimdiff.layout "LOCAL,BASE,REMOTE / MERGED"

kdiff3/meld 설정

1
2
3

git config --global merge.tool kdiff3
# 또는
git config --global merge.tool meld

추가 설정 옵션

병합 도구가 충돌 해결 성공을 종료 코드로 올바르게 표시하는 경우 mergetool.<tool>.trustExitCode 설정을 활성화할 수 있다.

1

git config --global mergetool.<tool>.trustExitCode true

백업 파일 생성 여부:

1

git config --global mergetool.keepBackup false

임시 파일 보존 여부:

1

git config --global mergetool.keepTemporaries true

임시 디렉토리 사용 여부:

1

git config --global mergetool.writeToTemp true

Mergetool 실행

1
2
3
4
5
6
7
8

# 모든 충돌 파일에 대해 병합 도구 실행
git mergetool

# 특정 파일만 병합 도구로 처리
git mergetool <file>

# 특정 도구 지정하여 실행
git mergetool --tool=<tool>

실전 충돌 사례 분석

사례 1: 동일 라인 변경 충돌

상황: 두 개발자가 같은 파일의 같은 함수를 서로 다르게 수정
충돌 내용:

1
2
3
4
5
6
7
8
9

<<<<<<< HEAD
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}
=======
function calculateTotal(items) {
  return items.reduce((total, item) => total + (item.price * item.quantity * (1 - item.discount)), 0);
}
>>>>>>> feature/discounts

해결 방법: 두 기능을 통합하여 할인 기능을 유지하면서 코드 표현 방식 개선
최종 코드:

1
2
3
4
5
6

function calculateTotal(items) {
  return items.reduce((sum, item) => {
    const discount = item.discount || 0;
    return sum + item.price * item.quantity * (1 - discount);
  }, 0);
}

사례 2: 삭제 - 수정 충돌

상황: 한 브랜치에서는 파일을 삭제했고, 다른 브랜치에서는 해당 파일을 수정
충돌 메시지:

1

CONFLICT (modify/delete): config.json deleted in HEAD and modified in feature/settings. Version feature/settings of config.json left in tree.

해결 방법:

1. 파일 유지 결정: git add config.json
2. 파일 삭제 결정: git rm config.json

사례 3: 서브모듈 충돌

상황: 두 브랜치에서 서브모듈이 다른 커밋을 가리키는 경우
충돌 내용:

1
2
3
4
5
6
7

diff --cc libs/ui-components
index 6335c9b,d245d31.
--- a/libs/ui-components
+++ b/libs/ui-components
@@@ -1,1 -1,1 +1,1 @@@
- Subproject commit 6335c9b4a49e431985fbebd415f3c68f3bfbeb1a
 -Subproject commit d245d31a2387c52e35bea88614618e5f9be5c271

해결 방법:

1. 서브모듈 디렉토리로 이동: cd libs/ui-components
2. 적절한 커밋 체크아웃: git checkout d245d31
3. 메인 프로젝트로 돌아와 변경사항 추가: cd../.. && git add libs/ui-components

사례 4: 리베이스 충돌 연쇄

상황: 리베이스 중 여러 커밋에서 연속 충돌 발생
해결 프로세스:

1. 첫 번째 충돌 해결 후: git add <files> && git rebase --continue
2. 다음 충돌 발생 시 반복 해결
3. 특정 커밋 건너뛰기 필요 시: git rebase --skip
4. 모든 충돌 해결 완료 시 리베이스 완료

최신 동향

16. 주목해야 할 기술

앞으로의 전망

하위 주제로 분류한 학습 확장 내용

추가 학습 주제

관련 학습 분야

용어 정리

참고 자료

• Git 공식 문서
• CHATMERGE 연구 논문
• Atlassian Git 튜토리얼
• Git 공식 문서 Conflict Resolution
• Atlassian Git Conflict Guide
• GitHub Docs - About merge conflicts
• Plastic SCM - Semantic Merge
• GitHub Copilot
• GitHub Codespaces
• Git 충돌 유형 및 해결 방법
• Atlassian Git 튜토리얼: 병합 충돌
• Git 병합 충돌 해결 팁
• Git 충돌 해결 가이드
• Git 문서: 고급 병합
• Git 문서: 병합 전략
• 서브모듈 충돌 관리 방법
• Git Mergetool 문서
• AI를 활용한 Git 충돌 해결
• Git 충돌 관리 모범 사례
• Atlassian Git 병합 전략 공식 튜토리얼
• Chuck’s Academy: Merge Strategies in Git
• Which Git merge strategy is appropriate for our team?
• Matillion: Mastering Git at Matillion - Merge Strategies
• Git의 새로운 기본 Merge 전략 ort (블로그)
• Stack Overflow: Merge made by ‘recursive’ strategy - git