어제에 이어 바뀐 형식대로 TIL을 작성해보려고 하는데 어떤 내용을 담아야할지 종일 고민이 많았습니다.
오늘은 Unity 프로젝트를 GitHub로 공유해서 협업을 진행할 때, 어떤 상황에서 충돌이 나는지 충돌은 어떻게 해결하는지 이야기해보고자 합니다.
오늘 팀 프로젝트가 마무리 단계에 접어들면서 팀원들의 작업 내용을 Merge해야 될 일이 많았습니다. 차근차근 Merge하며 프로젝트를 정리해나가던 중에 결국 충돌이 발생하고야 말았습니다.
Unity 프로젝트를 GitHub로 공유해서 협업을 진행할 때, 제가 가장 많이 충돌을 겪었던 부분은 같은 Scene을 수정했을 때였습니다.
Unity 프로젝트의 Scene 파일을 텍스트 편집기로 열어보면 정말 수많은 정보들이 담겨 있는 것을 확인할 수 있습니다.
그다지 복잡하지 않은 Scene임에도 불구하고 3000 줄은 가뿐히 넘어갑니다. 복잡할수록 줄은 길어지겠죠.
이러한 Scene 여러 명의 개발자가 같이 작업을 진행한다면 충돌이 안 날래야 안 날수가 없다고 생각합니다. 오브젝트의 Hierachy만 바꿔도 저 수많은 정보들의 위아래가 바뀌고 오브젝트 하나만 추가되어도 몇십줄의 정보들이 추가가 됩니다. 여기에 오브젝트 변경까지 한다면 엄청나겠죠.
프로젝트가 마무리 단계에 접어들면서 조금 긴장이 풀렸는지(?) 팀원 1명이 Scene을 복제해서 작업하지 않고 저와 다른 팀원이 작업하던 Scene에 무심코 개발을 진행해버렸습니다. (Scene을 복제해서 작업하는 것을 사전에 약속하고 프로젝트를 시작...)
결국 GitHub에서는 충돌로 인해 Merge를 허락해주지 않았죠...
사실 충돌이 났다는 사실 자체가 중요하진 않습니다. 당연히 여러 사람이 한 프로젝트에 작업을 하다보면 충돌이 날 수도 있죠. 하지만 지금 상황에서 중요한 건 앞서 말씀드렸듯이 같은 Scene에 작업을 하다가 충돌이 났다는 것입니다.
충돌을 해결하기 위해 GitHub에서 Resolve Conflicts를 눌러 충돌 사항을 확인해보면 위의 사진의 알 수 없는 값들이 섞여 있는 것을 확인할 수 있습니다. 이것을 수작업으로 해결하는 것은 거의 불가능에 가깝습니다. 이래저래 수정을 해서 GitHub에서 충돌 사항 안 뜬다고 끝이 아니기 때문입니다.
다시 Unity로 열었을 때 그 Scene이 문제없이 작동되는 경우는 정말 운이 좋은 겁니다.
어느 정도 한 번쯤은 일어날 수 있는 일이라고 생각했기 때문에 팀원들에게 한 번 더 이 상황과 사전의 약속을 강조하고 저는 이 문제를 해결하고자 하였습니다.
처음에는 충돌사항 자체가 엄청 많지는 않아서 GitHub의 Resolve Conflicts로 해결할 수 있지 않을까 싶었습니다.
하지만 역시 어느 브랜치의 것이 맞는 것인지 도저히 확인할 수가 없었고 억지로 해결하기에는 Scene을 열었을 때 어떤 사태가 벌어질지 알 수가 없었습니다.
결국 저는 충돌이 났던 Scene을 다른 Scene으로 복제한 후에 삭제하였습니다. 수정사항들만 잘 살려서 다시 새로운 Scene에 복제하는 방법으로 해결하고자 하였습니다.
다행이 충돌은 없어지게 되었고 Merge하여 다른 Scene에 모든 수정사항들을 옮기는 것으로 작업을 마무리할 수 있었습니다.
잘 해결이 된 후에 저는 팀원들에게 같은 Scene에 작업하는 것은 좋지 않다라는 것을 한 번 더 강조하였습니다.
사실 기존에도 같은 Scene에 여러 명이 작업을 하면 충돌이 많이 난다는 것은 알고 있었습니다. 이미 여러번 경험했었죠...
깨달은 게 있다면 사전에 계획하고 약속했다고 해서 모든 게 계획과 약속대로만 진행되지는 않는다는 것을 다시 한 번 상기할 수 있었습니다.
또한 이러한 상황에서 어떻게 단순히 프로젝트 수정사항에 대한 해결뿐만 아니라 팀원과의 소통을 어떻게 진행해야 하는지 한 번 더 생각해볼 수 있었습니다. 저희 팀은 서로를 탓하거나 하지 않고 문제에 대해 빠르게 파악하고 해결하기 위해 의견을 나누고자 노력하였습니다.
문제를 해결하고 나서는 문제에 대한 원인을 한 번 더 강조하고 해결방법을 설명하면서 문제를 마무리하였습니다.