Skip to main content

GIT PUSH 충돌 처리

onlydel

onlydel

충돌#

여러명의 개발자가 공동으로 동일한 저장소(repository)에서 프로젝트를 진행하면 대부분의 경우 충돌(conflict)을 경험하게 됩니다.

이 충돌들은 잘 해결해야 합니다.

하지만, 이 충돌들을 자동으로 해결해주는 VSCode git extension 등 외부 도구의 도움을 받게 되면 소스관리를 사용하는 의미를 잃게 될 수도 있습니다.

도구를 사용하면 충돌을 피하기 위해 새로운 브랜치(branch) 를 만들게 됩니다. 그 브랜치는 기본적으로 "Merge branch 'master' of https://github.com/realgrid/realreport" 와 같은 메시지를 기록하면서 기존의 브랜치와 머지를 하면서 커밋(commit)과 푸쉬(push)를 동시에 진행하게 됩니다. 여기에서 문제는 내가 풀(pull)명령을 통해 내 코드와 머지하지 못한 하나이상의 커밋들이 모두, 충돌을 회피하기 위해 만든 새로운 브랜치를 만든사람이 최종적으로 수정한것과 같은 기록을 남기게됩니다.

그렇다고 도구를 사용하지 않을 수는 없으니 잘 사용해야 합니다.

대부분 자동 머지는 내가 커밋을 미리 해 놓은 상태에서 풀을 받을때 발생합니다. 이를 피할수 있는 가장 쉬운 방법은 풀-커밋-푸쉬 의 순서를 유지하고 풀 할때 충돌이 발생하면 충돌할 파일을 미리 수정하는 것입니다.

실제 파일의 내용을 동시에 수정하여 충돌한 경우 의도하지않은 기록이 남을 수도 있습니다. 즉, 이전에 작업했던 작업자의 커밋을 내가 머지하면서 그 작업자의 수정내용이 나의 마지막에 작업으로 기록이 남을 수 있습니다.

또 다른 충돌의 문제는 이 새로운 브랜치의 머지로 인해 내가 이미 작업해서 커밋했던 코드의 내용을 다시 한번 내려 받게된다는 점입니다. 어쨌든 가능하면 충돌이 발생한 경우 순리대로 머지하는게 좋을것 같습니다.

충돌 이유#

충돌의 이유는 당연히 같은 파일을 서로 다른 작업자가 수정하고 같이 커밋을 할때 발생합니다. 하지만, 꼭 파일의 내용을 직접적으로 수정하지 않았더라도 VSCode 와 같은 편집기의 설정값에 따라 저장할때 자동으로 포멧을 변경하는 경우나 단순 실수로 스페이스나 엔터문자등이 들어 있어도 발생하게 됩니다. 소스파일 하나 하나의 수정내용을 잘 파악해야 겠지요.

충돌 회피#

충돌을 해결하기 위해서 여러가지 방법이 있습니다.

일단 표준적으로 아래 링크를 참조 하세요.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line

비 표준적이라고 말하기는 어렵지만 아래 제가 사용하는 방법 입니다. 이 방법은 충돌한 파일의 양이 많고 복잡한 경우 해결이 힘들수도 있습니다.

pull-commit-push 의 순서를 유지한다고 가정하고,

  1. pull 할때 충돌이 발생하는지 확인
  2. 충돌이 발생한 파일의 내용을 확인
  3. 복잡하지 않다면 내가 수정한 내용을 따로 저장
  4. 그 파일을 discard change
  5. 다시 pull
  6. 내가 수정한 내용을 그 파일에 적용
  7. 커밋
  8. 푸쉬

결론#

중요한 것은 pull을 할때 어떤 파일에서 충돌이 발생하는지 확인하고 충돌을 피하기 위해 최소한의 노력은 하는게 좋겠습니다. 하지만, 때로는 사정에 따라 강제로 머지하는게 합리적인 해결방법이 될 수도 있습니다. 소스코드를 관리하는데 너무 스트레스 받을 필요는 없으니까요.