commit rules
•
Feat : 새로운 기능을 추가하는 경우
•
Fix : 버그를 고친경우
•
Docs : 문서를 수정한 경우
•
Style : 코드 포맷 변경, 세미콜론 누락, 코드 수정이 없는경우
•
Modify : 자잘한 수정
•
Refactor : 코드 리펙토링
•
Test : 테스트 코드. 리펙토링 테스트 코드를 추가했을 때
•
Chore : 빌드 업무 수정, 패키지 매니저 수정
•
Design : CSS 등 사용자가 UI 디자인을 변경했을 때
•
Rename : 파일명(or 폴더명) 을 수정한 경우
•
Remove : 코드(파일) 의 삭제가 있을 때.
•
Add : 코드나 테스트, 예제, 문서등의 추가 생성이 있는경우
•
Implement : 코드가 추가된 정도보다 더 주목할만한 구현체를 완성시켰을 때
•
Move : 코드의 이동이 있는경우
•
Comment : 필요한 주석 추가 및 변경
branch / merge rules
•
브랜치는 main > develop > feature 3단계로 구성한다
•
main는 실제 출시하는 버전으로, 플레이 가능해야 하며, 가능한 수정 할 수 있는 버그를 모두 수정한 버전
•
develop은 master에서 따와서 각자 작업한 작업을 모으는 버전
•
feature는 각자 작업하는 브랜치로, develop에서 따와서 “feature/작업명” 과 같이 이름을 지어 사용한다
◦
각 feature에서 작업 할 때, 해당 작업 명에 해당하는 Scene을 생성하여 작업한다
•
그 외에 특별히 버그 수정을 한다면 그 시점의 develop에서 “bugfix/버그명” 브랜치를 만들어 사용한다
•
Pull Request를 하고 나서 slack으로 전달.
◦
merge를 하고 난 뒤, 자신의 branch 삭제 후 다른 branch에서 작업.
◦
자신의 것을 PR 하기 전, git rebase를 해줘 최신화 해주기!