Unity를 여러 개발자가 함께 개발할 때 프로젝트를 관리하려면 Github를 사용하는 것이 일반적이다.
평소 Github를 자주 사용했지만, 유니티를 사용할 때에는 여러가지 추가적인 작업들을 해주어야 해서 따로 정리해 둔다.
참고한 영상은 아래와 같다.
https://www.youtube.com/watch?v=wBsSUBEUYV4
목차
0. Introduction
Unity 프로젝트를 여러 명에서 진행하는 경우, Git 없이 프로젝트를 관리하려면 매번 수정사항이 있을 때마다 개발한 스크립트 또는 리소스들을 공유하기 위해 zip파일로 압축하여 공유하거나, 또는 유니티를 어느 정도 알게된 이후에는 Unity Package File로 묶어서 전달해야 한다.
하지만 이는 버전 관리를 해줄 수 없기 때문에 자칫 팀원들이 각각 수정한 내용들이 달라지게 될 경우 아래와 같은 문제점이 발생할 수 있다.
- zip파일이나 unity package file을 받아서 프로젝트에 적용하는 사람이 자신의 프로젝트에 적용하지 않는 경우
- 다른 사람에게 보낼 파일을 선택할 때 실수로 파일 몇 가지를 빼먹거나 수정하지 않은 파일을 같이 보내는 경우
- 특히 수정하지 않은 파일을 같이 보내는 경우, 다른 작업자가 그 파일에 많은 작업을 해둔 상태라면 큰 문제가 될 수 있다. 받아온 파일이 작업자가 수정한 파일을 덮어써버려 작업한 내용을 모두 날려버릴 수도 있다. 복구 또한 힘들다.
- 매번 최신 상태의 파일들을 관리하려면 용량이 매우 많이 필요할 것이다.
이 모든 문제를 해결하기 위한 방법이 바로 Git을 이용한 버전 관리이다.
이중 가장 친숙하고 널리 사용되는 Github를 사용해보려 한다.
이 글에서는 Github 사용법은 이미 알고있다고 가정하고 Unity를 위한 Repository를 생성하는 과정을 기록하려 한다.
1. Unity 프로젝트 관리를 위한 Repository 생성 과정
1) Github Repository 생성 (Remote Repository)
먼저 github에서 새로운 리포지토리를 만들어야 한다.
자신의 Github의 'Repositories' 탭에서 'New'를 선택한다.
여기서 일반적인 Repository 생성과 같이 새로운 Repository의 이름을 적고 설명을 넣어준 후,
'Add .gitignore'를 눌러 Unity 프로젝트 관리를 위한 gitignore 파일을 추가한다.
유니티에서는 에디터를 켤 때마다 내용이 바뀌거나 굳이 다른 개발자들과 공유하지 않아도 프로젝트를 진행하는 데 문제가 없는 파일들이 꽤 많이 존재한다.
이러한 파일까지 다 올리면 용량을 많이 차지할 뿐만 아니라, 필요한 파일을 찾아보기도 힘들어지기 때문에 .gitignore 파일에서 명시적으로 해당 파일은 remote repository에 업로드하지 않는 것이다.
Add .ignore 버튼을 잘 눌렀다면 상관 없지만, 혹시나 이미 repository를 만들어둔 상태라면 아래 링크에서 .gitignore파일을 따로 다운받아 해당 remote repository에 업로드하면 된다.
https://github.com/github/gitignore/blob/main/Unity.gitignore
GitHub - github/gitignore: A collection of useful .gitignore templates
A collection of useful .gitignore templates. Contribute to github/gitignore development by creating an account on GitHub.
github.com
2) Clone Repository (Local Repository 생성)
그 다음으로, Github Desktop을 열어서 (Source Tree, Git Bash 등 다른 것을 사용할 줄 안다면 알아서!) Clone Repository를 통해 로컬 리포지토리를 생성한다.
3) Unity Project 생성 및 푸시
이제 본격적으로 리포지토리에 유니티 프로젝트를 넣어주자.
먼저 Unity Hub에서 새 프로젝트를 만든다.
이때 방금 생성한 Local Repository에 프로젝트 폴더를 생성하도록 한다.
그 이후, Github Desktop에서 새로 생성된 내용들을 Commit 및 Push해준다.
이제 프로젝트 시작!
2. 깃허브의 기본 동작
깃허브의 사용법은 어느정도 숙지하고 있지만, 유니티 프로젝트를 진행할 때 알아두면 도움될 내용들을 조금 더 기록해둔다.
이 내용은 Github Desktop으로 Git을 관리할 때의 기준이다.
1) Commit
일반적으로는 변경된 파일에 대해서 통째로 Commit하고, 어떤 내용을 Commit하는지 Summary와 Description을 작성한다.
하지만 일부 내용은 빼고 Commit 할 수도 있다.
예를 들어, 위와 같이 파란색 부분이 수정된 내용이고, Commit할 부분인데, 위쪽 '32'라인을 보면 클릭을 통해 파란색이 해제된 것을 알 수 있다.
이 경우 파란색 부분만 Commit되는 것이다. (하지만 보통 올리고싶지 않은 부분은 주석처리한 후, 통으로 올리는게 대부분이긴 하다.)
2) Discard
Discard는 자신의 변경사항을 지우고, 파일을 마지막으로 커밋했던 상태로 되돌리는 것이다.
Reset과의 차이점은, Reset은 이미 푸시까지 된 상황에서 버전 자체를 되돌리는 것이지만, Discard는 수정된 내용에 대해서 되돌리는 것이다.
Commit과 마찬가지로 줄 단위로 Discard가 가능하고, 파일 단위로도 가능하다.
3) Push
푸시는 커밋된 내용을 Remote Repository에 업로드하는 것이다.
4) Pull
풀은 다른 사람이 작업한 내용, 즉 변경 사항을 Local Repository에 다운로드하는 과정이다.
수정한 내용들이 충돌이 발생할 수 있기 때문에, 내용을 수정하기 전에 항상 Pull을 실행하는 것을 습관화해주는 것이 좋다.
5) Merge
Pull로 가져온 사항과 자신의 변경 사항이 서로 충돌하는 경우에, 어느 커밋을 적용할지 결정하는 동작이다.
예를 들어, 'Script.cs'라는 파일에 대해서 개발자1은 Function1이라는 함수를 사용하여 파일을 수정하였는데,
개발자2가 Function2라는 함수를 사용하여 파일을 수정해두고 푸시까지 해버렸다고 가정하자. (즉, 개발자 1이 수정을 하는 동안 Remote Repository에 이미 개발자 2가 수정한 내용이 들어가있다는 의미이다.)
그 사실을 모르는 개발자1은 파일을 수정한 후에 Commit, Push를 실행할 것이다.
그때 아래와 같이, 새로운 커밋이 서버에 있으니 패치를 진행하라는 메시지가 출력된다.
Fetch를 누르게 되면, Pull을 통해 가져와야 하는 Commit이 존재한다고 알려주게 되고, 개발자2가 변경한 내용이 개발자1이 변경한 내용과 관련이 없는 부분이라면 문제없이 Pull이 가능하다.
하지만 같은 내용을 서로 다르게 수정한 내용이 있다면, 아래와 같이 Conflict(충돌)가 발생하게 된다.
이럴 때 사진의 'Open in Visual Studio Code'버튼과 같은 Merge 도구를 이용하여 충돌이 발생한 위치를 알아보고, 서로 협의를 통해 하나의 변경 사항만 선택하여야 한다.
만약 개발자1, 즉 새로 수정을 한 내용으로 하자고 협의가 된 경우 'Accept Current Change'를 선택하고
개발자2, 즉 개발자1이 수정하는 동안 Repository에 먼저 푸시한 사람의 코드를 선택하자고 결정난 경우 'Accept Incoming Change'를 선택하면 된다.
코드를 저장한 후, Merge 도구를 닫으면 Commit Merge 버튼이 아래와 같이 활성화된다.
3. Unity 프로젝트를 Github로 관리할 때 주의할 점
유니티 프로젝트를 깃허브로 관리하고, 협업을 진행할 때 주의할 점을 알아보자.
1) Unity의 버전 통일
가장 먼저, Unity의 버전을 통일해 주어야 한다.
호환이 되는것이 아니냐고 생각할 수 있겠지만,
유니티 프로젝트 버전을 관리할 때 가장 중요한 파일인 '.meta'파일의 내용이 유니티 에디터의 버전에 따라 달라질 수 있기 때문에
버전을 통일하는 일은 매우 중요하다.
따라서 버전이 다르면 메타파일들이 계속해서 불필요하게 변경 및 Commit되는 문제가 발생할 수 있다.
2) Asset 직렬화 방식
Unity 엔진에서 Prefab이나 Scene 등의 파일을 저장하는 방법은 '바이너리', '텍스트', 그리고 이 두가지를 섞어서 사용하는 혼합 방식이 존재한다. 이 세 가지 방식을 Asset 직렬화 방식이라고 한다.
최신 버전의 에디터에서는 기본적으로 텍스트를 사용하도록 설정되어 있는데, 만약 바이너리로 설정된 한 명의 개발자가 있다면 Github에서 관리가 어려워지고, 충돌이 발생했을 때 Merge 과정이 매우 복잡해진다. (바이너리 파일은 사람이 읽어서 해석하기 어려운 내용이다.)
하지만 텍스트의 경우 어느정도는 사람이 읽어서 해석을 할 수 있으므로, Asset 직렬화 방식은 '텍스트'로 통일해주도록 한다.
이를 바꾸기 위해서는 유니티 창 상단 메뉴바에서 'Edit → Project Settings → Editor → Asset Serialization Mode'를 'Force Text'를 선택해준다.
3) Version Control
유니티 엔진에서는 메타파일에 기록된 내용을 바탕으로 Scene에 포함된 오브젝트들을 관리한다.
그런데 'Edit → Project Settings → Version Control → Version Control Mode'가 개발자마다 다를 경우, 개발자들 간에 풀 및 푸시를 할 때 문제가 발생할 수 있다.
따라서 별도의 다른 버전 컨트롤 프로그램을 사용하는 것이 아니라면 'Visible Meta Files'로 통일하여 사용하길 권장한다.
최근댓글