Rules before starting a team project이란 팀 프로젝트를 시작하기 이전에 프로그래머들끼리 어떻 것들을 setting 좋은지에 관한 방법론을 적은 것입니다.
소규모 인디게임에 적합하게 만들었으며 개인 프로젝트에 적용해도 큰 무리 좋다고 생각합니다.
순서를 따로 정하지 않았으며 프로젝트, 취향에 맞게 적용하시면 됩니다.
가장 먼저 프로그래머, 기획 그리고 아트가 직접 엔진을 다룰 경우 unity 버전을 맞춥니다. 보통 버그가 없는 LTS 버전으로 맞춥니다.

Q1, LTS가 무엇인가요?
https://unity.com/kr/releases/lts-vs-tech-stream
저장소에는 여러 가지 종류가 존재합니다. 유니티에서 지원하는 Plastic SCM, 많은 사람들이 쓰는 Git, SourceTree, Fork 등이 있습니다.
저의 경우 GitHub Desktop을 설치해 이용하고 있습니다. 하지만 단점도 몇몇 있어 SourceTree와 연동해서 나중에 사용할 것 같습니다.

https://www.youtube.com/watch?v=wBsSUBEUYV4
따로 영상을 첨부했으면, 정리가 잘 된 블로그가 많아 쉅게 만들 수 있다.
C# Programming Nameing에 관해서 따로 posting 진행해서 보면 됩니다
https://velog.io/@whdrnr545/Unity-C-Programming-Nameing
Hierarchy & Aseets & ETC Management에 관해서 따로 posting 진행해서 보면 됩니다.
https://velog.io/@whdrnr545/Unity-Hierarchy-Aseets-Management

디스코드에서 채널을 만든 후

위 사진 처럼 디스코드 봇을 넣어 깃허브 push, merage 등등 메시지를 뜨게 합니다.
마찬가지로 정리가 잘 된 글이 많기에 한번 사용해봐도 좋을 것입니다.
https://eddori.tistory.com/entry/discord-github-webhook-%EC%97%B0%EB%8F%99
Github을 연결하였으니 그에 따른 규칙이 있어야 합니다.
공식적으로는 위 처럼 사용하지만 조금 변형하거나 팀만의 방식으로도 조금씩 달라집니다.
6가지 정도 방법을 제시했지만 더 좋은 방법이 훨씬 많을 것입니다. 결국 자신의 취향에 맞게, 규모에 대해 생각해보며 적절하게 적용해보는 것이 가장 좋습니다.
마지막으로 아래 글을 올리며 마무리하겠습니다.
https://unity.com/kr/how-to/organizing-your-project