프로젝트 그라운드 룰 및 규칙

[fkdl0048]

1984 프로젝트 사용 방법

기본적인 프로젝트에 관여하는 방법에 대한 설명입니다.

• PR, Issue, Discussion 사용 룰 설명서 #17

전에 이슈로 적어놓은 내용 + 구체화입니다..

구조

Root기준으로 Proceedings폴더에 프로그래밍 회의록이 작성됩니다.

Root기준으로 1984폴더는 Unity폴더입니다

유니티 폴더 구조

• 유니티 프로젝트 폴더 구조 모범 사례 #14

해당 구조를 참고하여 제작

회의록

예시

특별한 일이 없다면 대부분 전체 회의가 끝나고 플밍회의를 진행합니다. 테이블은 동일

한 주 동안 진행한 사항에 대하여 이야기, 회고를 진행합니다.

어느정도 틀이 잡히면 2주로 전환

Issue

이슈는 작업을 트래킹하기 위해 사용합니다.

최대한 자세하게 작성하기!

이슈에 들어가는 내용은 개발 예정 기능, 개발 중인 기능, 발생한 버그 등이 작성됩니다.

현재 제작된 템플릿 두개(기능, 버그)를 사용하여 작성해주시면 됩니다.

한 가지 작업을 트래킹

작업을 이슈로 두는 이유는 작업 자체를 세분화하고 해당 작업을 추적 및 바인딩하기 위함입니다.

현재 레포에서 해당 이슈로 브랜치를 만들고 해당 브랜치를 완수하는 목적성을 지님

한 가지 작업이라도 low level까지 세분화하여 작업을 적고 그대로 코딩하는 능력..

이슈에 작업을 적고 해당 작업에 대한 내용을 적을 때 정말 세세하게 적어야 합니다.

이미지가 있으면 더 좋음

Pull request

1. Reviewers: 자신을 제외한 팀원(리뷰 인원)
2. Assigness: 확인자, 해당 풀리퀘 작성자
3. Labels: 해당 기능에 맞게.. 추가 기능인지, 버그인지
4. Development: 해당 기능 이슈를 바인딩하여 자동으로 연동

풀리퀘는 이슈에 작성된 내용 즉, 기능 브랜치를 main으로 병합할 때 사용

1. 각 시스템은 독립적이기 때문에 해당 기능에 맞는 브랜치를 사용
2. 종속적인 기능 ex)Manager는 해당 브랜치로 전환하여 작성 후 병합
3. 풀리퀘가 생성되면 리뷰를 남은 사람을 등록하고 가능하다면 코드 리뷰형식으로 진행

풀리퀘도 이슈와 같은 작성방식을 가져감

해당 이슈와 바인딩하여 작성, 내용은 상세하게 바로 병합하지 않고 리뷰를 받고 확인되면 병합

종속적인 기능을 작업할 때

거의 발생하지 않겠지만 Manager의 경우 API를 추가하여 연결하는 작업의 경우..

앞 서 말한 해당 브랜치로 전환 후 Manager작업 후 현재 브랜치에 병합할 것.

나머지도 같은 형식으로 진행

Discussion

이슈에 적지 못하는 토론 내용을 작성

이야기가 필요한 내용 현재 프로젝트에 도움이 되는 자료, 해결해야 하지만 이야기가 필요한 내용 등등을 작성해주시면 됩니다.

작성방법은 직관적이라 idea, QnA등 해당 내용에 맞게 작성 부탁드립니다.

---

아직까지는 진행하며 전체적인 틀을 맞춰가는 단계라 적혀있는 내용이 전부 수정될 수 있습니다..!

[fkdl0048]

@ccmuk58 @kyoonge

위 내용으로 README에 올라갈 예정이라 한번 씩 읽어보시고 문제되거나 빠지거나 궁금한 부분 알려주세요!

지금 졸린상태로 작업해서 이상할 수 있스빈다..

++ 다시보니 이쁘지가 않아서,, 다시 천천히 고치겠읍니다.

[ccmuk58]

굉장하네요

[kyoonge]

와!!
넘 세세하게 잘 적어줘서 저만 잘하면 될 것 같아요!!
진짜 최고세요...😭