GIT 머지 충돌에 대한 고찰

git 으로 형상 관리를 할 때 동일한 파일의 같은 행을 같이 서로 다른 브랜치에서 작업을 하게 되면 충돌 이슈가 발생한다. 어떤 수정된 내용이 맞는 것인지 git 은 알수 없기 때문이다. 머지 충돌 문제는 혼자 개발을 할 때에는 주요 문제가 아니지만 실무에서 협업을 하다보면 한번씩 발생하게 되는데 이러한 머지 충돌 문제를 어떻게 해결하는게 효율적인지에 대해 적어둔다.

이 글은 지극히 주관적인 글임으로 맹목적인 신뢰를 지양하며, 하나의 참고 글로만 읽어주시기 바란다.

머지 충돌이 일어나기 전으로 돌아가자

머지 충돌이 발생하고 나서 머지된 브랜치를 지속 사용해야 한다면, 머지하기 이전의 커밋으로 돌아가야 한다. 이럴때는 ‘git reset, revert’ 등의 명령어를 사용하면 돌아갈 수 있으며 여기서는 가장 위험하지만 강력한 방법인 git reset 방법을 소개한다.

git reset --head [COMMIT ID]

각 commit 에는 고유의 ID 값이 존재하는데 해당 값을 활용하여 위의 명령어를 실행하면 프로젝트는 저 커밋이 실행된 직후 상황으로 복원된다. 주의해야할 점은 그 이후에 커밋했던 내역들이 모두 사라짐을 유의하자. (이를 살려야한다면 git revert 명령어를 참고하라)

이제 복원시킨 이 내용을 원격 저장소에도 동기화 시켜주기 위해 ‘git push’ 명령어를 실행하자

git push origin +master

Commit 이력등 도 변경이 되기 때문에 원격저장소 브랜치 명 앞에 ‘+’ 키워드를 붙여 줘야 한다

충돌난 내용이 서로 연관이 없다면? ( A + B = AB, BA )

머지 충돌이 발생했을 경우 이 이슈는 두 가지의 경우로 나뉜다. 첫번째는 서로 다른 두 브랜치에서 작업한 이 내용이 서로 관련이 없는 경우이다. 이런 경우에는 머지할 브랜치에 충돌된 두 브랜치의 작업 내용을 모두 포함시켜주면 된다. 두 브랜치 A, B 가 있다고 하자. 이 두 브랜치가 작업한 내용이 같은 파일의 같은 행에서 수정이 되었다. 이런 경우에 머지 충돌을 해결하기 위해서는 단순히 이 두 작업 A의 작업, B의 작업 를 연달아 호출하거나 반대로 B의 작업, A의 작업 호출하면 된다. 물론 연달아서 호출 시에 실제 비지니스에 문제가 있는지 없는지는 직접 보고 확인하여야 한다. 아래는 예시이다.

/* A 브랜치의 작업 */
AService aService = new AService();
aService.doSomething();

/* B 브랜치의 작업 */
BService bService = new BService();
bService.doSomething();

/* 머지되어야할 브랜치 */
AService aService = new AService();
aService.doSomething();
BService bService = new BService();
bService.doSomething();

머지 충돌을 위와 같이 수정하고 난 이후에 다시 A, B 브랜치에서 재 수정을 하게 되면 git은 알아서 서로 다른 행으로 인지하기 때문에 다시 머지 충돌이 일어나지 않는다. 지금 알아본 형태는 머지 충돌 이슈에서 다행히도 서로 연관된 값들을 사용하지 않기 때문에 간단하게 해결할 수 있는 방법이지만 다음에 볼 경우는 조금 더 복잡해진다.

충돌난 내용이 서로 연관이 있다면? ( A + B = C )

머지충돌이 골치가 아파오는 경우는 사실 대부분 이 경우이다. A 브랜치에서 작업한 내용, B 브랜치에서 작업한 내용이 서로 공유가 되는 부분이 있어서 실제 머지되는 브랜치에서는 A, B 두 브랜치에서 작업한 코드가 아닌 새로운 코드가 필요한 경우이다. 이와 같은 경우 C의 작업으로 머지되어야 할 브랜치에 수정을 하게 되면, A, B 브랜치에서 새로운 수정 작업이 생겨서 다시 머지를 하게되면 A, B 브랜치에는 새로운 C의 작업을 가지고 있지 않기 때문에 매번 충돌이 일어난다.

이를 해결하기 위해서는 어쩔 수 없이 지금 가지고 있는 브랜치로는 활용이 불가능하다. 그렇기 때문에 새로운 브랜치들을 모두 만들것이며 여기에 기존의 작업 내용들을 머지하면서 개선해야 한다.
추가적으로 우리는 PARENT 브랜치를 하나 더 만들 것인데 충돌이 나는 이 A, B 두 브랜치들은 이 PARENT 브랜치의 하위 브랜치로 생성을 한다. 이 하위 브랜치들은 PARENT 브랜치를 기준으로 작업내용을 서로 공유하며 진행한다.

즉 충돌난 내용이 서로 연관이 있다는 이야기는 즉 A, B 두 브랜치는 완전히 서로 독립적인 브랜치가 아니기 때문에 PARENT 라는 징검다리 브랜치를 만들어 머지가 되어야할 공용 브랜치를 보호하고 A, B 두 브랜치 간에 코드 공유도 가능하게 만든다. 아래는 이러한 머지 충돌이 났을 때 브랜치를 생성하는 예시이다.

git checkout master     : master 브랜치로 이동
git branch parent       : master 브랜치에서 parent 하위 브랜치 생성
git checkout parent     : parent 브랜치로 이동
git branch new_A        : parent 브랜치에서 new_A 하위 브랜치 생성
git checkout new_A      : new_A 브랜치로 이동
git merge old_A         : new_A 브랜치에 old_A 브랜치를 병합
git checkout parent     : parent 브랜치로 이동
git merge new_A         : parent 브랜치에 new_A 브랜치를 병합
git branch new_B        : parent 브랜치에서 new_B 하위 브랜치를 생성 (new_B 브랜치는 A의 작업을 포함하고 생성이 됨)
git checkout new_B      : new_B 브랜치로 이동
git merge old_B         : new_B 브랜치에 old_B 브랜치를 병합 (new_B 브랜치는 A작업을 가지고 있기 때문에 여기서 머지충돌이 일어남. 수동으로 개선 필요)
git checkout parent     : parent 브랜치로 이동
git merge new_B         : parent 브랜치에 new_B 브랜치를 병합