1. 컨벤션(Convention)

컨벤션이란, 협업 시 혼란을 줄이고 코드의 일관성을 유지하기 위해 정해놓은 팀 간의 규칙이다. 컨벤션의 종류는 다음과 같다.
1. 커밋 메시지 컨벤션
- Git에 커밋할 때, 메시지를 일정한 형식으로 작성하는 규칙
2. 코드 컨벤션
- 코드를 작성할 때 지켜야 할 스타일 가이드
- 클래스명, 변수명, 상수, 들여쓰기, 중괄호 위치 등
3. 파일명 / 폴더명 컨벤션
- 프로젝트 내 폴더/파일을 일관성 있게 구성하기 위한 규칙

2. Git으로 유니티 프로젝트 관리하기

1. 깃으로 유니티 연동한 레포지토리 생성

깃으로 유니티 연동한 레포지토리 생성 단계

1. 원하는 경로에 유니티 프로젝트 만들기  
2. 유니티 프로젝트 만들어 질 때까지 그냥 기다리기  
3. 유니티 창이 뜨는 것까지 확인하기  
4. 깃허브 데스크탑 열기  
5. 새로운 레포지토리 생성  
  
!주의! 유니티 프로젝트랑 동일한 경로에 git 생성  
ex) 유니티를 C드라이브>Test폴더에 만들었다 -> 깃도 C드라이브 Test 이름으로 만든다  
  
6. Initailize ~~ Readme.MD 체크  
  
!주의! 유니티 프로젝트랑 동일한 경로에 git 생성  
Git Ignore 반드시 Unity 로 선택  
  
7. 28~31개 정도 파일이 추가되어 있으면 정상  
8. 유니티에서 아무런 파일 추가하거나 삭제해서 확인해보기

유니티에는 관리 필요한 유니티의 3종 폴더들이 있다.

• assets
• packages - 추가 패키지가 들어가는 폴더(timeline, cinemachine)
• projectSettings

2. 에셋스토어 패키지 관리

에셋스토어에서 임포트하면 다운로드 받은 에셋도 깃에 포함된다. 그 이후 깃 푸쉬하면(publish) 내가 배포자가 되어버리는 문제가 발생한다. 따라서 다운받은 에셋들은 배포하지 않게 처리해야 한다. 따라서 다음과 같은 단계를 수행하면 좋다.

1. 다운 받은 파일을 Imports 폴더에 전부 넣기

2. changes 우클릭 - Ignore folder - /Assets/Imports

   • (Assets폴더에 내용물이 없으면 Ignore이 안뜸)

그러나 이 방법을 사용하면 협업 시 패키지가 공유되지 않아서, 프리팹 등을 사용 시 missing 오류가 발생한다. 따라서 이를 해결하기 위한 여러 방법이 있다.

1. 다운 받은 패키지 공유 - Export Package
2. 드라이브 등에 팀장이 매일 공유
3. Assets 폴더를 private으로 추가적으로 관리하기
   • README는 필요없음

3. git 관리 전략

git 관리 전략에는 3가지 방법이 있다.
1. 포킹 워크플로(Forking Wordkflow)
2. Github Flow
3. Git Flow

이 중 Git Flow에 대해 알아보겠다.

1. Git Flow

Git Flow는 많은 구성원이 라이브 서비스를 운영하는 조건에서 브랜치를 더 효율적으로 관리하기 위해 고안된 방식이다.

브랜치의 종류

• MASTER : 정식 버전 출시 및 빌드용 브랜치.
• DEVELOP : 기능개발이 진행되는 브랜치. 기능개발 진행시 여기에서 브랜치를 파생한다.
  • FEATURE : 디벨롭 브랜치에서 파생되며, 담당 기능개발 후 디벨롭 브랜치로 병합한다.
• RELEASE : 다음 버전 출시를 준비하는 브랜치. 디벨롭 브랜치를 여기로 옮긴 후 QA, 테스트 진행 후 MASTER로 병합 및 정식출시한다.
• HOTFIX : 정식 버전의 버그 수정 전용 브랜치

2. 브랜치 생성 및 사용방법

브랜치 생성: Github Desktop App에서 New Branch 또는 Github 웹사이트에서 New Branch

그래프 보기: Github Desktop App - open in Visual Studio Code - View Git Graph

제작 후 병합:
main(병합 받는 쪽을 선택)선택 - Choose a branch to merge into main - merge할 브랜치 선택 - Create a merge commit

merge의 종류:

• Create a merge commit: 기본 머지 방식, 모든 커밋을 유지한 채로 브랜치를 통째로 병합
• Squash and Merge: 커밋을 1개로 압축해서 병합
• Rebase: 커밋을 main에서 작업한 것처럼 재배열해서 머지

이후 추가로 merge할 브랜치는 삭제하는 것이 좋다.

3. 병합 충돌(Merge Confilct)

두 브랜치를 병합할 때 같은 파일의 같은 위치를 서로 다르게 수정했을 경우, Git이 어떤 것을 선택할지 몰라서 병합을 중단하는 상황이다.

이런 상황에서는 팀원들과 상의 후 병합을 하면 된다. 처리 방법은 갈라진 줄(<<<<, ====, >>>>)을 지운 뒤 정리한다. 또한 Visual Studio에서 병합 편집기에서 편집 시 편리할 수 있다.

유니티 충돌 안나게 사용하는 팁:
1. 팀원 마다 자신 이름의 폴더를 만들고 그 안에서만 작업(ex. 플레이어 컨트롤러를 내 폴더에서 만들기) 완성 이후 폴더 밖으로 빼내기
- 같은 파일을 건드리지 않게 하기 위함
- 완성 이후의 코드 수정은 크지 않기에 공통으로 작업해도 크게 위험하지 않다
2. 씬은 동시 편집 금지
- 씬의 파일은 C# 스크립트처럼 한 눈에 무슨 일이 일어났는지 파악하기 매우 어렵다.

4. 메타파일

유니티는 어떤 파일이건 전부 고유한 메타파일과 그 안에 guid을 가지고 있다. 직렬화가 가능한 이유는 해당하는 id를 찾아서 참조시키기 때문이다. 그러나 meta파일을 버전관리를 못하거나 소실되었을 때, guid를 찾지 못하고 계속 missing 오류가 뜬다. 따라서 메타파일을 항상 같이 관리해줄 필요가 있다.

만약 메타 파일이 안보인다면,

• Edit - Project Settings - Editor - Asset Serialization - Mode - Force Text
• Edit - Project Settings - Editor - Version Control - Mode - Visible Meta Files
  두 설정을 해주면 된다

5. 풀 리퀘스트(Pull Request, PR)

1. 풀 리퀘스트

풀 리퀘스트란 자신이 작업한 브랜치의 변경사항을 다른 브랜치로 반영해달라고 요청하는 것이다. 개발자가 독단적으로 메인 브랜치에 병합하는 것은 실수를 유발할 수 있기 때문에 풀 리퀘스트를 사용하는 것이 좋다.

병합 작업은 깃허브 데스크탑 앱에서 하는 것이 아니라 깃허브 사이트에서 풀 리퀘스트해야 한다.

PR 과정:

1. new pull request 이후 comment를 통해 토의 후 팀장이 merge 혹은 반려 가능
2. 병합 이후 병합시킨 branch를 삭제

또한 Github 웹사이트 - setting에서 규칙을 세팅할 수 있으며, Revert, Restore branch로 되돌리는 기능도 있다.

2. 충돌 처리 팁

PR 전에, 내 브랜치에 main 브랜치를 먼저 병합해보고, 충돌이 나는지 확인하고 해결한 후에 PR을 올려보면 좋다.

PR 생성 전에 충돌 여부를 미리 파악할 수 있으며, 충돌 해결을 자신이 직접 하므로 리뷰어 부담을 줄일 수도 있다.
충돌은 양방향 모두 충돌이 일어난다. 또한 A를 B에 붙이는 것이나 B를 A에 붙이는 것이 같은 내용이기에 자신의 브랜치에 병합 후 풀 리퀘스트를 하는 것이 도움이 된다.

또한 브랜치 중 메인(master)은 최후의 보루로써 웬만하면 건들지 않고, 개발할 때는(develop)에 붙이고 활용하는 것이 좋다. 메인에는 스프린트 끝나고 n차 결과물만 푸쉬하는 것이 용이하다.