PR, Issue, Discussion 사용 룰 설명서

[fkdl0048]

원래는 ReadMe에 적을까 했다가 나중에 수정이나 회고가 편하라고 여기에 작성합니다.

회의때 나왔던 내용을 한번 더 정리한 내용인데 많이 부족하니 github 협업 방법? 그런 쪽으로 개인이 공부를 해야 좀 더 유연하게 작업이 될 것 같습니다.

다른 프로젝트와 다르게 저희는 좀 더 소통을 많이 하고 서로 알려주고 성장하는 프로젝트가 되었으면 하네요..

저도 모르는 것과 아는 것에 대해 솔직하게 말하고 같이 생각해보는 좋은 작업이였으면 합니다..!

PR

회의 때 말씀드린 내용처럼 기능에 대한 브랜치(크게 잡고 커밋으로 구분)로 작업하는게 좋아 보입니다.

그전에 물론 어느정도 베이스 작업이 되야 의존성이 깨져서 각자 작업을 할 수 있을 것 같은데 지금이 그런 작업을 진행중인 것 같아요!

먼저 이슈에 개발 기능에 대한 설명 개발일정을 상세히 기재하여 팀원들이 서로 확인하며 어디까지 진행이 되었는지를 확인하는게 핵심입니다.

ex)

New Issue를 통해 기능 추가 탬플릿을 만들어서 내용을 작성

내부에서 기능을 세분화 하여 Task로 관리(모든 Task를 다시 이슈로 convert할 필요가 없고 해당 내용이 무겁다면 다시 이슈로 빼야합니다.)

해당 이슈를 기반으로 로컬에서 브랜치를 생성 후 풀리퀘를 만듬 원격에 업로드한 이후에 주기적으로 Master로 병합하여 충돌을 최소화

해당 풀리퀘에서 지속적으로 코드리뷰와 피드백을 진행

작업은 생산성이 목적이기 때문에 너무 비판적이지 않은 솔직한 피드백 진행

ex) 000변수명보다 직관적인 00느낌은 어떠세요..?

사실 이부분에 대해서 좀 더 이야기를 나눠봐야 할 것 같아요 동시에 진행되는 작업의 경우 rebase를 활용해서 작업을 하는 걸로 알고 있는데 각자 작업 시간대도 다르고 매번 확인할 수 없으니 이부분 같이 이야기해보고 조사해야 할 것 같습니다,

조금 더 좋은 방식 같아 보이는 건 fork를 떠서 각자 현재 디렉토리를 순수 codebase로 활용하는 살짝 더 들어가는 방법도 있는데 이것도 같이 이야기 해보면 좋을 것 같아요

Issue

이슈에 작성되는 내용은 조금 주관적일 수 있으나 대체로 기능에 관련된 내용이 들어가면 좋겠습니다.

만약 해당 기능에 대한 개발을 진행하던 중 막히게 되어 토론이 필요하면 그 이슈를 이래 Convert to discussion으로 옮기고 이야기하면 될 것 같습니다.

이슈에 관한 예제는 탬플릿 양식과 지금까지 작성된 이슈를 참고하시면 됩니다.

버그도 마찬가지로 양식에 맞춰 작성 부탁드립니다.

즉, 프로젝트에 필요한 기능, 버그만 작성해주시면 됩니다.

예제는 지금까지 작성된 이슈 보시면 될 것 같습니다.

Discussion

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

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

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

예제입니다.