
충돌(Conflict) 해결하기
지난 포스팅에서 충돌이 발생하는 상황을 만들어 봤습니다.
[Git_32] 충돌(Conflict) - 충돌이란? & 충돌 상황 만들기
개요(충돌 이란?) 지금까지 Git의 기본적인 사항은 대부분 확인을 해봤습니다. 하지만, 이 외에도 아직도 많은 기능들이 있습니다. 많은 기능들이라기보다 실제 우리가 협업을 하다 보면 발생할
wishlan.tistory.com
이렇듯 충돌이 발생하면
결국 직접 코드를 보고 hotfix에서 수정한 개발자와
master에서 수정한 개발자가 함께 살펴보면서 수동으로 해결해야 합니다.
충돌이 발생한 파일을 열어보면 충돌이 발생한 지점에
Git은 충돌된 코드의 내용을 기호를 포함해 표시해 주고 있습니다.
충돌이 발생한 fileb.html을 열어보면 다음과 같습니다.

확인한 바와 같이 충돌이 발생하면
<<<<<<< HEAD와 ======= 사이의 내용이
기준이 되는 브랜치의 내용이며,
즉 실습에서는 master 브랜치의 소스 내용이 되겠습니다.
그다음의 =======부터 >>>>>>> hotfix (대상 브랜치 이름)까지의 내용이
대상이 되는 브랜치의 소스 내용이 되겠습니다.
실습에서는 대상이 되는 브랜치 이름이 hotfix 이므로
>>>>>>> 뒤에 hotfix라고 표시되고 있습니다.
여기서 잠시 참고로 얘기하면,
VSCode를 편집기로 사용하게 되면
이와 같은 충돌이 발생한 코드를 열었을 때
편의성과 생산성을 높이기 위한 옵션을 제공하고 있습니다.

위와 같이 흐릿한 메시지로 표시되고 있는 것이 있습니다.
① Accept Current Change,
② Accept Incoming Change,
③ Accept Both Changes,
④ Compare Changes
로, 4가지 옵션을 메뉴로 제공하고 있습니다.
① Accept Current Change : HEAD 부분을 적용합니다.
② Accept Incoming Change :
반대로 병합 대상이 되는 브랜치의 내용을 적용합니다.
③ Accept Both Change :
기준이 되는 HEAD부분과 대상이 되는 브랜치의 내용 모두 적용합니다.
이걸 사용할 경우는 거의 없었습니다.
④ Compare Change :
충돌 난 부분을 비교하기 편하게 새 탭으로 좀 더 보기 쉽게 보여줍니다.
충돌한 내용을 수정할 때는 Git에서 표시한 충돌 기호도 함께 삭제해서 수정합니다.
저는 다음과 같이 수정하고 저장하였습니다.

충돌한 파일을 수정했으면, 다시 커밋을 실행해야 합니다.
충돌을 해결한 것 자체가
파일을 다시 수정한 결과와 같으므로 파일은 modified 상태가 됩니다.
그래서, 다시 스테이지에 올리고 커밋하는 과정이 필요하겠습니다.
저는 -am 옵션을 사용해 다시 커밋을 진행했고,
그 실행 화면이 다음과 같습니다.

그 결과 다시 커밋이 정상적으로 실행되었고,
(master | MERGING)으로 표시되는 것도
정상적으로 (master)라고 표시되는 것을 알 수 있습니다.
소스트리에서도 다음과 같이 문제없이 잘 병합되었음을 알 수 있습니다.

소스트리에서도 충돌을 해결할 수 있습니다.
앞서 충돌이 발생한 상황으로 되돌아가보면 다음과 같았습니다.
충돌이 발생하면 ‘스테이지에 올라간 파일’ 영역과
‘스테이지에 올라가지 않은 파일’ 영역 모두에 파일이 표시됩니다.

이때, ‘스테이지에 올라가지 않은 파일’ 영역에 있는 파일을
클릭해 보면 오른편에 충돌 내용을 확인할 수 있습니다.

충돌한 파일에 마우스 오른쪽 버튼을 클릭하면
나타나는 팝업 메뉴에서 [충돌 해결] 메뉴에 마우스를 가져가면
다음과 같이 다양한 해결 옵션 메뉴를 확인할 수 있습니다.
![소스트리(Sourcetree)에서 fileb.html 파일 [충돌 해결] 메뉴](http://t1.daumcdn.net/tistory_admin/static/images/xBoxReplace_250.png)
이 옵션들을 사용해서 간단히 충돌을 해결할 수 있습니다만,
가능하면 앞서 해 본 바와 같이 수동으로 수정하는 것을 추천합니다.
그게 가장 안전하기 때문입니다.
또, 외부 병합 툴 시작이라는 메뉴를 이용하기 위해서는
외부 툴을 설정하는 등의 소스트리 설정이 필요합니다.
여기서는 [‘내 것’을 이용해 해결] 메뉴를 실행해 보겠습니다.
선택하면 다음과 같이 다시 한번 확인하는 창이 나타납니다.
[확인]을 클릭합니다.

그러면, 다음과 같이 뭔가 병합이 안되고 변화가 없습니다.
![[충돌 해결] 메뉴 실행 후 소스트리의 커밋 이력 확인](https://blog.kakaocdn.net/dn/bT7VKZ/btrWdHEk9Vq/gNIeclXgRPY1l5f4cDfGG0/img.png)
터미널에서 Git의 상태를 확인해 봅니다.
충돌은 해결되었으나 아직 병합 중이라는 것을 알 수 있습니다.
그리고, 병합을 끝내려면 “git commit”을 사용하라는 메시지를 확인할 수 있습니다.

소스트리에서 “파일 상태” 메뉴를 클릭해 봅니다.

그럼, 커밋을 할 수 있는 준비가 되어 있습니다.
커밋 메시지를 작성하고 [커밋]을 클릭합니다.
그 결과 다음과 같이 병합이 완료되어 새로운 커밋 정보가 생성되었음 알 수 있습니다.

소스트리에서 충돌을 해결하는 과정도 잠시 살펴봤지만,
이렇게 해결하는 경우는 거의 없다고 생각됩니다.
참고만 하고 가능한 직접 수동으로 해결하는 것이 좋겠습니다.
간단하게 병합 과정에서 충돌이 발생한 상황을 살펴봤습니다.
이러한 충돌은 실무 하는 과정에
Git이 아니더라도 버전 관리 시스템에서는 흔하게 발생하게 됩니다.
그래서 최대한 예방하기 위해 작업자 간에 적절한 규칙을 정하는 경우가 많습니다.
가령, master의 내용을 자주 자신의 브랜치로 병합하게 합니다.
최소 커밋한 후 병합해 다른 수정사항이 없는지 확인하도록 해서
병합 과정에서 충돌이 발생하는 경우를 최소화합니다.
지금까지 Git에서 충돌(Conflict)이 발생하는 상황과
충돌을 해결하는 과정을 살펴봤습니다.
감사합니다.
'코딩해보니 > Git' 카테고리의 다른 글
[Git_35] 리베이스(rebase) - 이해하기(개념 잡기) (0) | 2023.01.24 |
---|---|
[Git_34] 리베이스(rebase) - 무작정 따라하기 (1) | 2023.01.17 |
[Git_32] 충돌(Conflict) - 충돌이란? & 충돌 상황 만들기 (0) | 2023.01.14 |
[Git_31] 브랜치(Branch) 삭제, 이름변경 그리고 ... (0) | 2023.01.10 |
[Git_30] 브랜치(Branch) 병합(Merge) (0) | 2023.01.04 |