1️⃣ GitHub를 사용하면서..
이전 팀원들과 프로젝트를 진행했을 때는 팀원 중에 프로젝트 경험이 많고, GitHub를 잘 다루는 팀원이 있어서 그분이 Merge를 담당하면서 Conflict도 해결해줬다. 그리만 이번 프로젝트에서는 나를 포함해서 GitHub 사용경험이 많은 분이 없어서 경험도 쌓을 겸 내가 Merge를 주로 도맡아서 하면서 Conflict를 해결하려고 했다.
내가 처음으로 develop 부분과 Merge를 했을 때는 당연히 Conflict이 나지 않았지만, 팀원이 develop 부분에 Pull Request를 올려서 Merge를 실행 했을 땐 Conflict이 났다.
Conflict이 난 부분을 대부분 수정하고 Merge를 실행했는데, 그 뒤로 develop 브랜치에서 프로젝트가 열리지 않는 문제가 발생했다. 그래서 Merge한 부분을 Revert시키고 수동으로 하나씩 Merge를 해봤다. 그랬더니 프로젝트가 열리지 않는 불상사는 생기지 않았다.
자동으로 Merge했을 때, Conflict이 나면서 Conflict을 해결해도 프로젝트가 깨져서 열리지 않은 이유를 찾아보니..'.gitattributes' 때문일 수도 있다는 블로그의 글을 보게되었다.
*.gitattribute에 .pbxproj binary merge 을 적용하면 project.pbxproj 파일을 바이너리화 하여 브랜치 merge시 충돌을 방지할 수 있다.
잦은 충돌로 스트레스를 받는 상황에서 분명한 유혹이 될 수 있다. 하지만 이 설정에는 충돌방지의 편의 그 이상의 위험성이 내포되어 있다.
프로젝트를 열 수 없는 대참사를 불러올 수 있기 때문이다.
그 이유는 병합될 두 project.pbxproj 안의 중괄호의 위치가 어긋나게 되는 경우가 있어, 파일 전체의 정합성에 문제를 일으키기 때문이다.
더욱이 문제가 되는 것은 분명히 충돌이 일어났음에도 일반적인 충돌상황과는 달리 아무런 문제없이 병합된 것처럼 파일에 >>>>> HEAD나 <<<<브랜치이름 이 안보여진다는 것이다!
따라서 github Desktop이나 gitKraken 같은 버전관리툴에서 편하게 병합관리가 불가능하며, 손으로 일일히 정합성을 판단해 고쳐야 한다. 하지만 이렇게 될 경우 정상적으로 병합됐는지 처음부터 하나하나 세심히 살펴보아야 하며 많은 시간적, 정신적 비용이 발생할 수 있다.**
