[Git] 3.3. Branch간의 충돌 : Conflict

업데이트:

카테고리:

태그: , , , , , ,

병합 커밋 및 충돌 해결

branch를 나누었을 때 두 커밋이 같은 코드를 수정했다면 병합 커밋을 만들다가 충돌이 날 수 있다. 때문에 여러 개발자가 함께 쓰는 [master] branch에는 바로 병합하지 않고, 나만 쓰는 branch (여기에서는 [feature/cart])에서 먼저 병합해보고 문제가 없는지 확인한다. [feature] branch를 기준으로 병합하는 것이다.

이후 병합된 커밋이 문제가 없다면 이를 [master] branch에 반영한다.


병합 과정

img_17

[feature] branch를 기준으로 병합하기로 하였으므로 위와 같이 [feature/cart] branch로 checkout해준다.

img_18

[master] 브랜치의 최신 커밋에서 [병합]을 선택한다.

img_20

위와 같이 병합 충돌이 발생했다는 팝업창이 뜨는데 닫기를 누른 후, 스테이지에 올라가지 않은 파일을 살펴본다. (충돌이 난 경우 해당하는 파일은 스테이지에 올리지 않는다.)

img_21

문제의 파일인 iTshirt-cat/feature-list.md 파일을 SourceTree에서 살펴보니 위와 같았다.

img_19

수정을 위해 위의 파일을 IntelliJ에서 열어보았다. Git에서 자동으로 충돌한 부분에 대해서 표시를 해줌을 확인할 수 있었다. 다만 markdown 파일의 경우 ‘>’ 표시는 인용의 초록색 박스로 들어가서 IntelliJ의 미리보기에서는 괴기한 모습으로 보이는 것은 감수하자.

우리는 위의 코드를 보며, 3번이 중복되었음을 직관적으로 확인할 수 있다. 때문에 두 코드를 모두 살리며 번호를 수정해주는 것으로 판단했고, 판단대로 수정해보자.

img_22

위와 같이 수정할 수 있었다.

img_23

SourceTree로 돌아가보니, feature-list.md 파일의 미리보기에서 »>나 «<, === 등의 충돌 표기가 없이 정상적으로 수정이 반영된 것을 확인할 수 있었다. 정상이므로 stage에 add한 뒤, commit과 push를 이어가보자.

img_24

conflict(충돌)에 대한 내용이 commit message에 자동으로 표시된 것을 확인할 수 있다. 이 메세지를 바꾸지 않고 그대로 커밋하겠다. 바로 push 기능을 체크 해제하여 push 과정을 분리하겠다.

img_25

위의 사진처럼 정상적으로 [feature/cart] branch에 merge되었음을 알 수 있다. 바람직하게 conflict를 해결한 것이다.

img_26

SourceTree에서 상단의 Push를 눌러 [feature/cart] branch에 정상적으로 push해보았다.

img_27

push가 완료되었고, 이 [feature/cart] branch를 [master] branch에 반영해보자.

img_28

[master] branch로 checkout한 뒤, 최신 커밋인 ‘Merge branch…’ 커밋을 우클릭 한 뒤, [병합]을 선택한다.

img_29

[master] branch의 포인터가 최신 커밋으로 온 것을 확인할 수 있다.

img_30

다만 local에서만 [master] branch로 병합된 것이고, [origin/master]에는 반영되지 않았을 것이므로 위와 같이 push를 통해 원격저장소에도 반영해준다.

img_31

실제로 GitHub의 iTshirt/iTshirt-cat 폴더의 feature-list.md 파일을 확인해본 결과, cat과 oct의 작업내용과 그 충돌을 수정한 최종 feature-list.md 파일이 반영되었음을 확인할 수 있었다.


Reference

  • 팀 개발을 위한 Git GitHub 시작하기, 한빛미디어, 정호영,진유림

댓글남기기