[Git] merge

#Git

이번 포스트에서는 git merge에 대해서 다뤄보겠다.

merge는 말 그대로 병합을 하는 기능이다.
브랜치끼리 합쳐준다.

기본 merge

그래서 이게 왜 필요한걸까?

git으로 작업을 하다보면, 기능별로 나누기 위해서든, 분업을 하기 위해서든, 배포를 관리하기 위해서든, 아무튼 브랜치를 쪼개서 개발을 하게 된다.

만약 master를 기본 배포 브랜치로 하고 develop을 개발용 브랜치로 한다면,
develop으로 먼저 작업을 해서 어느정도 작업이 완성되고 난 다음에, develop의 작업사항을 master에 통합해야 하는 식으로 진행이 된다.

그럼 이런식으로 develop에 commit을 하다가

이렇게 merge로 master에 합쳐주면 되는 것이다.

그런데 이렇게만 되면 참 좋겠지만... 현실은 그렇지 않다.

merge conflict

위의 경우에는 깔끔하게 맞물려있는 구조라서 Fast-forward로 바로 직통 merge가 성공했는데, 문제는... 그렇지 않을 경우가 많다.

만약 병합하는 2개의 브랜치가 하나의 소스파일에 대해서 각각 수정을 했다면, 어느놈을 반영해줘야 하겠나?
이게 자연스럽게 겹쳐진다면 git이 알아서 해결을 해주기도 하는데, 그렇지 않다면 충돌을 직접 해결해야 한다.

한번 상황을 재현해보겠다.

master에서는 저렇게 수정을 하고

develop에서는 이렇게 수정을 했다.

이 상황에서 merge를 한다면, 무조건 충돌이 발생한다.

그도 그럴것이, lhs_1로 바꾸는게 맞는지, lhs_2로 바꾸는게 맞는지 git이 어떻게 알겠나?

그래서 이런식으로 선택지를 준다.

Accept Current Change를 선택하면 현재 브랜드로 덮어씌우고, Accept Incoming Change를 하면 가져오는 브랜치로 덮어쓴다.
Accept Both Change로 하면 둘다 합쳐버리긴 하는데... 억지로 합쳐버리는지라 결과가 이상할때가 더 많아서 쓰지 않는걸 권한다.