본문 바로가기
Devops/Git

[Git] Conflict 해결하는 방법

by J4J 2021. 5. 8.
300x250
반응형

안녕하세요. J4J입니다.

 

이번 포스팅은 Conflict 해결하는 방법에 대해 적어보는 시간을 가져보려고 합니다.

 

 

Conflict 발생 이유

 

conflict는 주로 서로 다른 브랜치에서 동일 파일의 동일 위치에 있는 코드를 수정한 뒤 변경된 소스코드를 합치는 과정에서 발생됩니다.

 

예를 들어 master브랜치를 카피하여 A, B라는 브랜치를 생성을 했다고 가정해보겠습니다.

 

그리고 기존에 master브랜치에 C라는 파일이 있었고 C라는 파일에는 hello master라는 텍스트가 있었다고 하면 A, B 브랜치에도 동일하게 C라는 파일이 있고 hello master라는 텍스트가 작성되어 있을 겁니다.

 

이 상황에서 A브랜치에서는 C파일의 텍스트를 hello A라고 수정하여 master브랜치에 merge되면 master브랜치의 C파일의 텍스트 값이 hello A로 수정이 될 겁니다.

 

그리고 B브랜치에서는 C파일의 텍스트를 hello B라고 수정한 뒤 A브랜치와 동일하게 master브랜치에 merge되면 conflict가 발생됩니다.

 

왜냐하면 B브랜치는 master브랜치의 C파일이 hello master로 알고 있는데 hello A로 변경되어 있어서 다른 브랜치를 통해 코드가 변경되었다는 것을 인식하고 너네들이 토론해서 하나의 변경점으로 통일해라라는 의미로 conflict를 발생시킨 것입니다.

 

Conflict 발생 상황

 

 

발생 케이스

 

위에서 말씀드린 케이스를 기반으로 하여 실제로 Conflict를 발생시켜보겠습니다.

 

[ 1. Repository 생성 후 C파일 생성 ]

 

C파일 생성

 

 

[ 2. 브랜치 A, B 생성 ]

 

브랜치 생성

 

 

브랜치 생성하는 법을 모르시는 분은 여기를 참고해주세요.

 

 

[ 3. A브랜치에서 C파일 변경 ]

 

A브랜치에 관련된 작업은 ConflictTest_A라는 폴더에서 작업을 해보겠습니다.

 

bash에서 A브랜치에 접근하여 C파일을 수정한 뒤 A브랜치에 push를 해보도록 하겠습니다.

 

C파일 수정 후 push

 

 

반응형

 

 

[ 4. B브랜치에서 C파일 변경 ]

 

B브랜치에 관련된 작업은 ConflictTest_B라는 폴더에서 작업을 해보겠습니다.

 

A브랜치에서 했던 것과 동일하게 C파일을 수정한 뒤 push를 해보도록 하겠습니다.

 

C파일 수정 후 push

 

 

[ 5. master브랜치에서 A, B 브랜치 fetch ]

 

이제는 다시 master브랜치를 담당하는 폴더로 돌아가서 원격 저장소에 저장되어 있는 A, B 브랜치에 대한 정보를 localStorage로 가져와보도록 하겠습니다.

 

사용되는 명령어는 git fetch입니다.

 

A, B 브랜치 fetch

 

 

[ 6. A브랜치 merge ]

 

git merge 명령어를 이용하여 master브랜치에 A브랜치의 변경사항을 merge해보도록 하겠습니다.

 

A브랜치 merge

 

 

병합한 뒤 C.txt 파일을 확인해보니 hello A로 정상적으로 반영되어 있는 것이 확인됩니다.

 

 

[ 7. B브랜치 merge ]

 

이번에는 A브랜치가 merge 된 master브랜치에 B브랜치를 merge 해보겠습니다.

 

B브랜치 merge

 

 

merge명령어를 사용하게 되면 위처럼 conflict가 발생되는 것이 확인됩니다.

 

conflict 발생 이유는 위에서 말씀드린 것처럼 동일 파일에 동일 위치에 있는 코드를 수정했기 때문입니다.

 

 

728x90

 

 

Conflict 해결 방법

 

이제는 위처럼 발생된 conflict를 해결해보도록 하겠습니다.

 

[ 1. git status를 통해 merge 되지 않은 파일 확인 ]

 

git status

 

 

git status명령어는 add를 하기 전 변경이 일어난 파일을 확인하는 명령어로도 사용되지만 위처럼 merge되지 않은 파일을 확인하는 명령어로도 사용됩니다.

 

Unmerged paths:라는 곳을 보면 C.txt 파일이 merge되지 않았다고 친절하게 표현해주고 있습니다.

 

이렇게 확인된 파일들의 conflict를 해결하는 방법은 간단합니다.

 

소스코드를 확인한 뒤 알맞은 코드를 선택하여 파일을 수정해주면 끝입니다.

 

 

[ 2. Conflict가 발생된 파일 소스코드 수정 ]

 

소스코드 수정

 

 

merge 되는 과정에서 conflict가 발생된 파일들을 확인해보면 위처럼 << HEAD == >> origin/B 이런 식으로 표시가 되어있습니다.

 

간단히 말씀을 드리면 << HEAD부터 == 까지는 현재 저장소에 작성되어 있는 소스코드를 의미하고 ==부터 >> origin/B까지는 merge대상인 B브랜치에 작성되어 있는 소스코드를 의미합니다.

 

conflict를 해결하기 위해서 C파일에 접근하여 정말 필요한 소스코드들만 내버려둔 뒤 저장을 해주겠습니다.

 

 

[ 3. commit후 저장소에 push ]

 

commit후 push

 

 

conflict 해결한 후 commit을 해주면 MERGING이라는 표시가 사라지게 됩니다.

 

conflict가 해결되었다는 것을 의미하고 commit된 파일들을 원격 저장소에 push해주면 원격 저장소에도 merge된 소스코드가 올라가게 됩니다.

 

 

[ 4. 원격 저장소 확인 ]

 

저장소 commit 확인

 

 

 

 

 

이상으로 Conflict 해결하는 방법에 대해 간단하게 알아보는 시간이었습니다.

 

읽어주셔서 감사합니다.

728x90
반응형

댓글