[2월 정기세션] Git merge 문제 해결

 

안녕하세요! GDSC Sungshin 교육팀 김나은입니다!

 

 2월 정기세션에서 교육팀은 ' Git merge 문제 해결 '이라는 주제로 교육을 진행했습니다.

 

솔루션 챌린지를 하면서 한번쯤은 경험해볼 수 있는 Git merge 문제에 대해 알아보고 해결 방법까지 알아보도록 하겟습니다!

 

 

목차로는 Git이 무엇인지, Git merge와 Git merge 충돌이 무엇인지 알아보고 마지막으로 Git merge 충돌 방법을 해결하는 방법으로 진행하도록 하겠습니다

깃이란 여러분의 모든 파일들의 버전 히스토리를 가지고 있는 오픈소스 분산 버전 컨트롤 시스템입니다. 

덕분에 여러분에 원하는 버전으로 언제든지 되돌아갈 수 있습니다.
여러분 혼자서 또는 여러사람이 프로젝트 파일들을 쉽게 관리할 수 있도록 도와주는 시스템이라고 할 수 있습니다.

여기서 깃과 깃허브의 차이점에 대해 궁금하실 수 있습니다. 

깃은 로컬 파일의 변경사항을 기록하고 여러 사용자 간의 작업을 조율하기 위한 버전 관리 시스템입니다. 

깃허브는 깃을 클라우드 형식으로 구현한 버전 관리 시스템입니다. 

로컬 파일을 깃허브 클라우드에 Push(업로드)하여 서로 다른 위치에 있는 여러 사용자가 작업할 수 있습니다.

간단하게 말해서 깃을 커피라고 하면 깃허브는 커피샵이라고 할 수 있습니다.

 

 

Git merge는 현재 파일들의 내용을 이전 버전들과 동기화하는 기능입니다.
동일한 파일에 새로운 변경 사항을 반영하기 전에 다른 개발자들이 수정한 내용들을 통합하는데 도움을 줍니다.

만약 여러분이 abc.txt라는 파일을 만들고 Git 저장소로 푸시(push)했다고 가정해봅시다.

이 때, 이 파일은 현재 버전에 해당합니다. 

만약 여러분의 동료가 같은 파일을 수정하고 저장소에 푸시했다면, 그 파일은 새 버전을 가지게 됩니다.

우리가 깃 머지에 대해 알아야 할 것은 2가지 입니다.

먼저, 변경사항입니다.

두 버전의 파일 사이에 어떤 유형의 작업이 수행되었나? 새로운 내용이 추가되었는지, 제거되었는지, 또는 기존 내용을 업데이트했는지 알려줍니다.

 

두번째는 가능성입니다.
가능성은 수정이 파일 내 다른 영역에 발생했는지 아니면 같은 영역의 파일에 발생했는지 2가지의 가능성이 있습니다.

 여기서 같은 영역이라는 의미는 개발자들이 파일 내 가까운 지역의 내용들을 각자 수정했다는 의미입니다. 

예를 들어, 같은 문단이거나 같은 라인을 의미합니다.

 

 

다음은 Git merge 충돌입니다.

 

Git의 auto-merge 기능으로 대부분의 문제가 해결되지만
같은 파일 내에 같은 영역에서 수정이 발생한 경우 Resolve the Merge Conflicts라는 메시지를 받게됩니다.

 

 

알렉스와 티나, 두 명의 개발자들의 이야기를 예시로 하겠습니다.
알렉스가 원격 저장소로에서 그의 로컬 저장소로 수정사항을 pull 했습니다.
그가 abc.txt라는 파일을 수정하고, 스테이징하고, 커밋한 뒤 마침내 원격 저장소에 이를 push했습니다.
그 동안, 알렉스가 abc.txt 파일을 수정한지 알아채지 못한 티나가 파일의 같은 영역에 일부 코드를 수정하고 원격 저장소로 push를 시도했습니다.

버전 관리 시스템인 Git으로부터 티나는 현재 원격 저장소에 있는 파일보다 오래된 버전의 파일을 수정했다는 경고 문구를 확인했습니다. 

알렉스가 이미 원격 저장소의 것을 수정했기 때문입니다.

이제, 티나는 우선 원격 저장소로부터 수정사항을 pull 받고, 파일을 업데이트한 다음 다시 푸시를 해야 해야합니다.
티나가 작업을 수행했으나, auto-merge 실패라는 문구가 떴습니다. 

그래서 그녀는 merge conflict를 해결해야만 하는 상황입니다.

 

 

일단 티나가 수정사항을 pull하게 되면,

티나의 로컬 파일에는 그녀의 수정사항과 Alex의 수정사항이 함께 존재하게 됩니다.
이 때 티나가 생각할 수 있는 4가시 사항은

1. 알렉스의 수정사항을 유지하고 그녀의 것을 제거하기
2. 알렉스의 수정사항을 지우고 그녀의 것을 유지하기
3. 알렉스의 수정사항과 그녀의 수정사항 둘 다 유지하기
4. 알렉스와 그녀의 수정사항 모두 지우기

가 있습니다.

 

먼저 상황 1인 파일의 같은 영역에 수정사항이 있을 경우 입니다.

 

 

같은 영역에서 여러 수정사항이 있어 Git이 auto-merge를 수행하지 못할 경우, 화면에 보이는 특수 문자들로 충돌 지역을 표시합니다.
첫번째와 두번째 특수 문자 사이에는 여러분의 로컬 환경의 수정사항들을 가르킵니다. 

이 수정사항들은 아직 원격 저장소에 반영되지 않은 상태입니다.
두번째와 세번째 특수 문자 사이에는 원격 저장소 또는 다른 브랜치의 수정사항들을 가르킵니다.

코드 사진을 보시면 충돌이 발생하여 auto-merge를 수행할 수 없는 파일의 내용들을 보여줍니다. 

충돌 지점은 로컬에서 - Sleep이라는 코드를 추가하여 수정한 부분에 있습니다. 

그동안 누군가가 같은 영역에 ‘- Gym’이라는 코드 한 줄을 추가한 수정내용을 push한 상황입니다.

 따라서 - Sleep 은 로컬 환경의 수정사항으로, - Gym은 원격 저장소나 다른 브랜치에서 incoming되는 수정사항으로 인식됩니다.

 

 

만약 - Sleep이나 Gym만을 살리고 싶다면, 그것만 살리고 나머지 충돌 부분은 제거합니다.
둘 다 살리고 싶다면 충돌 지점을 알려주는 기소들만 삭제하고 수정을 반영하고 싶지 않다면 모두 삭제해주면 됩니다.

수정을 하고나서 충돌 지점을 알려주는 기호(<<<<<<<, =======, >>>>>>>)들이 남아있지 않도록 확인해야 합니다.

 

 

수정이 끝나면, 다음과 같이 진행해야합니다.

수정사항을 스테이징(Stage) 하고
메시지와 함께 수정 사항들을 커밋하고
마지막으로 원격 저장소로 수정사항을 푸시합니다.

이렇게 파일의 같은 영역에서 수정 사항이 있고 머지 충돌이 발생했을 때 해결방법입니다.

 

 

두번째 사례는 다른 브랜치에서 한 개발자가 파일을 수정하는 동안, 또 다른 개발자가 자신의 브랜치에서 동일한 파일을 삭제한 상황입니다. 

이 경우, 여러분은 파일을 유지하고 싶은지 아니면 지우는 것이 옳은지 판단해야 합니다.

 

 

저희는 파일을 없애는 것으로 선택을 하고 실습을 진행하겠습니다.
삭제된 파일을 여러분의 브랜치에 다시 추가하기 위해, 제일 위에 보이는 코드를 작성합니다.
그 다음 파일을 제거하는 코드를 작성해서 오류가 발생한 파일을 제거합니다.
메시지와 함께 수정사항을 커밋한 후 푸시를 하면 충돌 문제가 해결됩니다.

 

 

머지 충돌을 해결하는 동안 무엇을 살리고 무엇을 삭제할지 결정하는 것이 가장 중요합니다.
앞에서 진행한 예제들은 GitBash를 사용하거나 또는 다른 Git CLI로 머지 충돌을 해결한다는 점을 가정하고 진행했습니다. 항상 코드를 작성하기 전에 pull를 받는 것을 습관화 해야 머지 충돌을 방지할 수 있습니다.

이상으로 2월 정기세션 발표를 마치겠습니다.

 

다음 포스팅도 기대해 주세요! :)