GitHub 사용규칙

[편집기록]

날짜	내용	버전	작성자
2019-11-09	Home에 있던 링크들을 이 곳으로 옮김	1.0	김기표

---

⭐ Branch 전략

구조

• master
  • hotfix
  • develop
    • feature/기능이름
    • fix/기능이름
    • refactor/기능이름

브랜치 설명

• Master 브랜치 : 마스터 브랜치는 배포용 브랜치이고 마일스톤에 따라 tag를 단다
• Hot fix 브랜치 : 핫픽스 브랜치는 배포 및 테스트시 발생된 버그들을 빠르게 고치는 브랜치이다.
• Develop 브랜치 :실제 개발이 쌓이는 브랜치 기능개발 수정 리팩토링은 feature, fix, refactor 등과 같은 하위브랜치를 사용해서 개발한다. 목요일 7시에 master로 PR을 날린다.
• feature/기능이름 브랜치 : 피쳐를 중심으로 기능을 개발하는 브랜치, PR은 develop 브랜치로 날린다.
• fix/기능이름 브랜치 : 기능 오류를 수정하는 브랜치, 피쳐중심의 기능 오류를 해결하는 브랜치로 PR은 develop 브랜치로 날린다.
• refactor/기능이름 브랜치 : 오탈자나 코드의 최적화와 같은 수정을 위한 브랜치이다. PR은 develop 브랜치로 날린다.

⭐ PR 규칙

• PR template을 이용한다.
• 코드리뷰는 적어도 한 사람이 approve 했을 경우에만 merge
  • 머지 커밋을 남긴다. ex) merged by @gg And reviewed by @raccoonback

⭐ Commit 규칙

제목

포멧 : {prefix}: {변경 내용}

• prefix
  • 기능 추가 : feat:
  • 인터페이스 추가 : ui:
  • 오류 수정 : fix:
  • 잡다한 일 : chore
  • 리팩토링 : refactor:
  • 파일추가 : add:

본문

포멧 : {prefix}: {내용}

• prefix
  • 이유 : why:

⭐ 프로젝트 규칙

• projects / milestone
  • 실제 개발해야할 피쳐들을 projects 에 이슈로 올린다.
  • 매주 Iteration 을 정해서 작업해야할 목표 작업량을 산출하여 개발한다.
  • 개발자 지정
• 배포 전략
  • CI 도구 : Github Actions
  • master 브랜치
    • 코드 스타일 분석, 테스트, 빌드 진행한다.
    • 브랜치에 merge 될 때마다, master server에 배포한다.
  • develop 브랜치
    • 코드 스타일 분석, 테스트, 빌드 진행한다.
    • 12:00 자정에만 dev-server 에 배포한다.

⭐ Issue Template document

• Bug Report
  • 버그발생시 사용하는 이슈 템플릿
• Feature Request
  • 백로그에 작성된 혹은 스프린트당시 작성된 피쳐를 제외하고 당장 추가해볼만한 혹은 추가해야하는 피쳐를 설명하는 이슈 템플릿
• Help
  • 도움이 필요하거나 질문이 있을 때 사용하는 이슈 템플릿
• Feature
  • 백로그 피쳐를 이슈에 올릴때 사용하는 이슈 템플릿