[Unity] 협업 준비

Git

---

Git Commit message 규칙

1. 제목과 본문을 빈 행으로 구분한다.
2. 제목을 50글자 내로 제한한다.
3. 제목 첫 글자는 대문자로 작성한다.
4. 제목 끝에 마침표 넣지 않는다.
5. 제목은 명령문으로 사용하며 과거형 사용하지않는다.
6. 본문의 각 행은 72글자 내로 제한한다.
7. 본문은 어떻게 보다 무엇을 왜 개발하였는지 설명한다.

Git branch 분기 관리

개발과정에서 독립적으로 코드를 분리하고 관리하기 위한 시스템으로 작업 과정에서 코드를 통째로 복사해야하는 과정 없이 전환하여 실행이 가능하다. 독립적인 코드 구성으로 다른 개발 과정에 영향을 주지 않으며 병렬적으로 작업하는 것이 가능하며 분기를 구성하고 다른 분기 사이를 이동하면 언제든 다른 작업을 병행해서 개발하는 것 또한 가능하다.

Git Flow 프로세스

1. master : 프로젝트의 최종 결과물들이 보관되는 분기이자 외부에 공개되는 버전 → 웬만해서 건드리지 않고 무결성을 유지해야한다.
2. develop : 개발 구성원들이 기능 개발 시작 지점으로 선정하는 분기로, 세부 기능까지 개발이 완료되고, QA 및 테스트 이후 master에 붙인다.
3. feature : 하나의 기능을 개발하는 분기로 기능 개발이 완료되면 develop에 붙인다.

Git 관리 전략 수립시 고려사항

1. git conflict의 원인은 같은 파일에 같은 위치에 상이한 내용을 작성한 경우이므로 같은 파일을 2명 이상이 건드리는 경우는 역할 분담이 제대로 안되었다는 의미이다. 따라서 이를 방지하기 위해 개별 클래스는 1명이 담당하는 등 역할 분담을 확실하게 하여 작업을 하는 것이 좋다.
   → 개발 도중에는 팀원마다 폴더를 만들어서 스크립트, 씬을 관리한다.
   → 완성되었다고 생각되는 경우 그때는 공용 폴더로 옮겨서 모두 사용이 가능하도록한다.

2. 씬은 동시에 편집하는 것이 아니다. 충돌이 생길 경우 일반 스크립트의 몇십배에 해당하는 충돌을 확인해야하며, 해결하더라도 참조 오류와 같은 에러가 생길 확률이 굉장히 높다. 따라서 씬을 수정하고자 하는 경우 복사해서 개인 폴더에 넣은 뒤 수정하고, 다시 복사해서 원래 파일에 붙여넣는 식으로 한다.

3. 씬에 작업을 바로하는 것보다 테스트 씬을 새로 만들어 단위 테스트를 하는 방식으로 진행하는 것이 안전하다. 만약 프리팹을 만들어 기능 테스트를 할 경우, 개인 폴더에 테스트 씬을 만들어 해당 씬에서 테스트하는 것이다. 혹은 애초에 단위 테스트 씬을 공용으로 만들어 놓고, 테스트가 필요할 때 해당 씬을 복사하여 사용하는 방법도 좋다.

4. meta파일은 유니티에서 어떤 종류의 데이터라도 반드시 함께 생성되는 파일로, 고유한 GUID를 가지고 있어 인스펙터 상에서 드래그&드롭이 필요한 경우 구분 용도로 사용된다. 따라서 메타 파일이 없으면 유니티가 파일을 찾지 못하고, 동일한 파일이라 하더라도 GUID가 다른 메타 파일인 경우 찾지 못하는 상황이 생긴다.
   → 버전 관리시 메타 파일도 함께 관리할 필요가 있다.
   <참고> 메타 파일이 보이지 않는 경우 아래의 설정을 해준다.
   → Edit - Project Setting - Editor - Asset Serialization - Force Text
   → Edit - Project Setting - Version Control - Visible Meta

5. Merge를 진행할 때 독단적으로 main Branch에 바로 합치는 것이 아닌, PullRequest를 활용하는 것이 바람직하다. PullRequest는 진행한 커밋들을 main 브랜치에 병합할 수 있도록 요청하는 것이다. PullRequest가 들어오면 회의를 통해 Merge 여부를 판단한 뒤 진행하는 것이다.
   <참고> PullRequest시 충돌 여부는 바로 확인이 가능하다.

6. PullRequest를 하기 전에 main 브랜치를 나의 브랜치에 Merge하여 테스트하는 것도 가능하다. 만약 PullRequest에서 문제가 생기는 경우, main 브랜치를 가져오는 경우도 당연히 충돌이 생긴다. 이때 해당 충돌을 해결하여 브랜치를 보완하는 경우, 이후에 진행하는 PullRequest와 Merge에는 아무런 문제가 없다.

주의사항

에셋 스토어에서 에셋을 다운 받고 깃에 커밋한 뒤 push를 하는 경우 배포자가 되어버리기 때문에, 다운 받은 에셋은 깃에 올리지 않을 필요가 있다.
→ Imports 폴더 생성 후 다운 받은 에셋은 모두 이곳에 저장
→ Github에 들어가서 Imports 파일 아무거나 우클릭(Imports.meta 제외)
→ Ignore folder(add to. gitignore) - /Assets/Imports 클릭
→ 깃허브가 해당 폴더를 무시할 수 있도록 한다.
→ 이후 Imports 파일만 따로 관리하는 레포지토리를 생성하여 private으로 publish 한다.

Github 실습

새로운 레포지토리 생성, Git ignore : Unity 선택

<참고> 유니티의 경우 필요한 폴더는 Asset, Packages, ProgramSetting이다.

원하는 경로에 유니티 프로젝트 만들기

깃허브 데스크탑 연동 확인1

하이어라키 창에서 큐브 생성

깃허브 데스크탑 연동 확인2

이전 버전 확인(checkout commit)

Imports 폴더 생성, 정크 파일 추가 → Gitignore 등록

프로그래밍 작업 절차

---

프로그래밍 과정 5단계

1. 인지
   • 구현해야 할 프로그램의 요구사항 인지, 나열
   • 전체적인 기능과 동작 나열
2. 분석
   • 인지 단계에서 나열된 정보글에 대한 세부내용을 정리
   • 문제의 입출력, 데이터 형식을 식별하고 추가 요구사항 및 제약사항 고려
3. 설계
   • 이전 단계를 통해 도출된 데이터를 기반으로 기능의 절차를 단계적으로 기술
4. 구현
   • 이전 단계에서 설계한 알고리즘을 프로그래밍 언어로 기술
5. 검증
   • 구현된 프로그램과 코드를 구동하고 테스트, 디버깅

설계 과정을 거치지 않은 코드의 문제점

1. 객체의 의존도가 상승
2. 객체의 책임을 생각하지 않은 무분별한 기능 추가가 진행된다.
3. 해결해야할 문제를 한 눈에 파악하기 어렵다.
4. 팀원간의 협업을 어렵게 한다.

UML

클래스 다이어그램

클래스 내부의 정적인 내용이나 클래스 사이의 관게를 표기하는 다이어그램이다. 시스템의 일부 또는 전체의 구조를 나타내며, 의존관계를 명확히 보여주기 때문에 순환 의존이 발생하는 지점을 찾아내서 어떻게 이 순환 고리를 깨는 것이 가장 좋은 지 결정하게 해준다.

플로우 차트

플로우 차트는 순서도, 흐름도라고도 하며, 어떠한 일을 처리하는 과정을 순서대로 간단한 기호와 도형으로 도식화한 것을 의미한다. 미리 정의된 기호와 연결선으로 알고리즘이나 프로그램의 논리 혹은 흐름을 그림으로 표현하는 방법이다.