까다로운 Git 병합 충돌 해결 방법 단계별 안내

이 종합적인 단계별 가이드를 통해 Git 병합 충돌의 복잡성을 탐색해 보세요. 수동 편집 및 외부 도구를 사용하여 충돌을 식별, 검토 및 해결하는 방법을 배웁니다. 복잡한 시나리오를 위한 전략, 향후 충돌을 최소화하기 위한 모범 사례, 그리고 자신 있게 코드베이스를 관리하여 보다 원활한 협업 개발과 효율적인 버전 관리를 보장하는 방법을 알아보세요.

28 조회수

어려운 Git 병합 충돌 단계별 해결 방법

Git은 협업과 코드 관리를 용이하게 하는 강력한 분산 버전 관리 시스템입니다. 매우 유용하지만, 개발자가 마주치는 가장 흔한 문제 중 하나는 병합 충돌을 해결하는 것입니다. 이는 Git이 서로 다른 브랜치에서 동일한 파일의 동일한 부분을 수정한 변경 사항을 자동으로 조정할 수 없을 때 발생합니다. 이 가이드는 가장 복잡한 Git 병합 충돌조차 해결하기 위한 체계적인 단계별 접근 방식을 제공하여 보다 원활한 개발 워크플로우를 보장합니다.

효과적인 Git 사용을 위해서는 병합 충돌을 이해하는 것이 중요합니다. 두 개의 브랜치가 분기된 후 병합될 때 Git은 변경 사항을 결합하려고 시도합니다. 두 브랜치에서 동일한 코드 줄이 다르게 수정되었다면 Git은 이를 충돌로 표시합니다. Git은 추측하는 대신 병합 프로세스를 중지하고 어떤 변경 사항을 유지할지 또는 어떻게 결합할지를 결정하기 위한 수동 개입을 요구합니다.

Git 병합 충돌 이해하기

병합 충돌이 발생하면 Git은 영향을 받은 파일 내에서 충돌 섹션을 표시합니다. 이러한 마커는 충돌이 어디에 있는지, 그리고 각 브랜치에서 어떤 변경이 이루어졌는지 정확히 식별하는 데 도움이 됩니다. 기본 마커는 다음과 같이 보입니다.

<<<<<<< HEAD
// 현재 브랜치의 코드 (HEAD)
이것은 현재 브랜치의 코드 버전입니다.
=======
// 병합 중인 브랜치의 코드
병합하려는 브랜치의 코드 버전입니다.
>>>>>>> <branch-name>
  • <<<<<<< HEAD: 현재 브랜치(병합 대상 브랜치)에서 충돌하는 섹션의 시작을 나타냅니다.
  • =======: 두 브랜치의 충돌하는 변경 사항을 구분합니다.
  • >>>>>>> <branch-name>: 충돌하는 섹션의 끝을 나타내며, 병합 해오는 브랜치의 이름을 보여줍니다.

당신의 임무는 이 섹션들을 편집하고, 충돌 마커를 제거하며, 코드의 최종 버전을 결정하는 것입니다.

단계별 충돌 해결 워크플로우

병합 충돌을 효과적으로 해결하려면 체계적인 접근 방식이 필요합니다. 권장되는 워크플로우는 다음과 같습니다.

1. 충돌 파일 식별

충돌이 발생하는 git merge 명령을 실행한 후 Git은 어떤 파일에 충돌이 있는지 알려줄 것입니다. git status를 사용하여 "Unmerged paths" 목록을 볼 수도 있습니다.

git status

이 명령은 다음과 유사한 출력을 표시합니다:

On branch main
Your branch is up to date with 'origin/main'.

Unmerged paths:
  (use "git add <file>..." to mark resolution)
  (use "git restore --staged <file>..." to unstage)
  (use "git merge --abort" to abort the merge)

    both modified:   path/to/your/file.txt

2. 충돌 검토

git status에서 "Unmerged paths"로 나열된 각 파일을 엽니다. 이 파일 내에서 충돌 마커(<<<<<<<, =======, >>>>>>>)를 찾아 충돌하는 코드 블록을 구분합니다. 마커 사이의 코드를 주의 깊게 읽고 두 브랜치에서 이루어진 변경 사항을 이해합니다.

3. 파일 수동 편집

이것이 충돌 해결의 핵심입니다. 각 충돌 마커 블록에 대해:

  • 최종 코드 결정: 유지할 코드 버전 또는 두 버전을 결합해야 하는지 결정합니다.
  • 마커 제거: <<<<<<< HEAD, =======, >>>>>>> <branch-name> 줄을 모두 삭제합니다.
  • 변경 사항 통합: 원하는 결과를 반영하도록 코드를 편집하고, 문법적으로 올바르고 논리적으로 타당한지 확인합니다.

예시:

example.txt 파일이 다음과 같다고 가정해 봅시다.

This is the first line.
<<<<<<< HEAD
This line was changed on the main branch.
=======
This line was changed on the feature branch.
>>>>>>> feature-branch
This is the last line.

검토 후 feature-branch의 버전을 유지하기로 결정했습니다. 파일은 다음과 같이 편집됩니다.

This is the first line.
This line was changed on the feature branch.
This is the last line.

만약 두 코드를 결합하거나 새로운 코드를 작성하고 싶다면 다음과 같이 할 수 있습니다:

This is the first line.
This line was changed on the main branch, but also has a feature.
This is the last line.

4. 해결된 파일 스테이징

파일을 편집하고 해결에 만족하면 해당 파일의 충돌이 해결되었음을 Git에 알려야 합니다. 이는 파일을 스테이징 영역에 추가하여 수행합니다.

git add path/to/your/file.txt

충돌을 해결한 모든 파일에 대해 이 작업을 반복합니다.

5. 병합 커밋

해결된 모든 파일을 스테이징한 후에는 커밋하여 병합을 완료할 수 있습니다. Git은 일반적으로 병합이 성공했고 충돌이 해결되었음을 나타내는 기본 커밋 메시지를 제공합니다.

git commit

그러면 구성된 Git 편집기가 열려 커밋 메시지를 검토하고 최종 확정할 수 있습니다. 편집기를 저장하고 닫으면 병합이 완료됩니다.

외부 병합 도구 사용

복잡한 충돌의 경우나 시각적 인터페이스를 선호하는 경우, Git이 외부 병합 도구를 사용하도록 구성할 수 있습니다. 인기 있는 옵션은 다음과 같습니다.

  • KDiff3
  • Meld
  • Beyond Compare
  • Visual Studio Code (Git 통합 포함)

Git을 특정 도구(예: meld)를 사용하도록 구성하려면:

git config --global merge.tool meld
git config --global mergetool.prompt false

충돌이 발생하면 다음을 실행할 수 있습니다.

git mergetool

그러면 각 충돌 파일에 대해 구성된 도구가 열리고 세 가지 비교(기본, 로컬, 원격)와 출력 창이 제공되어 차이점을 시각화하고 해결하기가 더 쉬워집니다.

git mergetool 사용 워크플로우:

  1. git mergetool을 실행합니다.
  2. 도구가 첫 번째 충돌 파일에 대해 열립니다.
  3. 도구의 인터페이스 내에서 충돌을 해결합니다.
  4. 변경 사항을 저장하고 도구를 닫습니다.
  5. Git은 종종 해결된 파일을 자동으로 스테이징합니다.
  6. 충돌하는 모든 파일에 대해 반복합니다.
  7. git mergetool로 모든 파일을 해결한 후 병합을 커밋합니다: git commit.

복잡한 시나리오 처리

1. 병합 중단:

압도당하거나 해결 과정에서 실수를 했다고 판단되면 언제든지 병합을 중단하고 병합 시도 전 상태로 돌아갈 수 있습니다.

git merge --abort

이것은 작업 디렉토리를 사전 병합 상태로 재설정하는 안전한 방법입니다.

2. 전략 옵션:

때로는 Git이 병합을 시도하는 방식을 영향을 미치고 싶을 수 있습니다. git merge -s <strategy> 옵션을 사용하면 이를 수행할 수 있습니다. 일반적인 전략에는 recursive(기본값), resolve, 그리고 ours/theirs(특정 시나리오에서 한 브랜치의 변경 사항을 압도적으로 수락하려는 경우 유용할 수 있음)가 있습니다.

예를 들어, 병합 중 변경 사항에 대해 theirs 버전을 선호하려면 (극도로 주의하여 사용):

git merge -X theirs <branch-name>

3. ours vs. theirs 이해하기:

병합 전략 또는 충돌 해결을 다룰 때 ours는 현재 위치한 브랜치( git merge를 실행한 곳)를 의미하고, theirs는 병합 해오는 브랜치를 의미합니다.

4. 리베이스 충돌:

git rebase 중에 충돌이 발생하면 프로세스는 비슷하지만, 변경 사항을 해결하고 스테이징한 후 git commit 대신 git rebase --continue를 사용합니다.

# 리베이스 중 충돌을 해결하고 파일을 스테이징한 후
git rebase --continue

리베이스를 중단하려면:

git rebase --abort

충돌 최소화를 위한 모범 사례

  • 자주 풀링: 기능 브랜치로 메인 브랜치의 변경 사항을 정기적으로 가져와 동기화를 유지하고 작은 충돌을 점진적으로 해결합니다.
  • 소통: 누가 코드베이스의 어느 부분에서 작업하고 있는지 팀과 조율합니다.
  • 짧은 수명의 브랜치 유지: 오래 실행되는 브랜치는 더 큰 분기와 복잡한 충돌이 발생하기 쉽습니다.
  • 코드 모듈화: 잘 구조화되고 모듈화된 코드는 겹치는 변경 사항이 적은 경향이 있습니다.

결론

Git 병합 충돌은 처음에는 부담스러울 수 있지만, 협업 개발의 관리 가능한 부분입니다. 충돌 마커를 이해하고, 체계적인 해결 워크플로우를 따르고, 도구를 사용하거나 중단해야 할 때를 알면 이러한 상황을 자신 있게 처리할 수 있습니다. 이러한 기술을 정기적으로 연습하고 모범 사례를 따르면 프로젝트에서 병합 충돌의 발생 빈도와 복잡성을 크게 줄일 수 있습니다.