1. 이슈 생성

Assigneers

해당 작업의 담당자 (=이슈의 작업자)

Labels

해당 작업의 성격
GitHub에 Issue나 Pull Request에 Label을 지정할 수 있는데, 기본적으로 9개의 Label이 제공된다.
+본인이 원하는 라벨을 직접 만들 수도 있다.

keyword	의미
bug	예기치 않은 문제 또는 의도하지 않은 동작(버그)을 나타냅니다.
documentation	문서를 개선하거나 추가 할 필요가 있음을 나타냅니다.
duplicate	해당이슈 또는 PR이 기존에 있음을 나타냅니다.
enhancement	새로운 기능 요청을 나타냅니다.
good first issue	처음 기여해볼 사람에게 좋은 문제를 나타냅니다.
help wanted	관리자가 문제 또는 PR 요청에 대한 도움을 원함을 나타냅니다.
invalid	이슈 또는 PR 요청이 더 이상 관련이 없음을 나타냅니다.
question	이슈 또는 풀 요청에 추가 정보가 필요함을 나타냅니다.
wontfix	문제나 PR 요청에서 작업이 계속되지 않음을 나타냅니다.

참고 : https://help.github.com/en/github/managing-your-work-on-github/about-labels

Project

위에서 만든 Projects 중에서 하나를 선택하면 된다. ex) Week1, Week2, Week3

Milestone

프로젝트가 도달해야 하는 목표지점을 지정해두는 것이다. 예를 들어, 3주동안의 프로젝트라면 Projects를 만든 것과 같이 주 단위의 목표를 나눠서 Week1, Week2, Week3로 할 수도 있고, 어떤 A라는 기능을 만들어야 한다면 그 기능에 대한 마일스톤을 만들 수도 있다. 그래서 진행상황을 표현할 수 있다.

• issue 탭에서 milestone 버튼으로 new milestone을 생성할 수 있다.

Development

이슈에 branch를 생성할 수 있다.

브랜치명 규칙

1. master branch
   제품으로 출시될 수 있는 브랜치

2. develop branch
   다음 출시 버전을 개발하는 브랜치
   즉, 배포 가능한 안정적인 상태라면 develop 브랜치를 master 브랜치에 merge(병합)한다.
   평소에는 이 브랜치를 기반으로 개발을 진행한다.

3. Supporting branches
   평소에 자주 사용하는 브랜치로 팀 구성원 간에 평행 개발을 하게 하고 기능을 쉽게 추적할 수 있다.
   이 supporting 브랜치들은 메인 브랜치와는 달리 결국 제거될 것이므로 항상 제한된 수명을 갖는다.

   1) feature branch
   브랜치명: feature/{issue-number}-{feature-name}
   기능을 개발하는 브랜치
   새로운 기능 개발 및 버그 수정이 필요할 때마다 develop 브랜치로부터 분기한다.
   * feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에 자신의 로컬 저장소에서 관리한다.
   개발이 완료되면 develop 브랜치로 merge하여 다른 사람들과 공유한다.
   develop 브랜치에서 feature branch를 로컬에 생성하는 방법

   	git checkout -b feature/{function} {develop Branch}

   2) release branch
   브랜치명: release- 또는 release/
   이번 출시 버전을 준비하는 브랜치
   배포를 위한 전용 브랜치로 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능을 개발할 수 있다.
   1팀은 1.2버전을 개발하고 2팀은 1.3버전을 개발한다.
   release 브랜치는 배포를 위한 최종적인 버그 수정, 문서 추가 등 배포와 직접적으로 관련된 작업을 수행한다.
   이러한 작업들 이외에 release 브랜치에 새로운 기능을 추가로 merge하지 않는다.

   3) hotfix branch
   브랜치명: hofix-
   출시 버전에서 발생한 버그를 수정하는 브랜치

   배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, master 브랜치에서 분기하는 브랜치이다. develop 브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기도 어려우므로 바로 배포가 가능한 master 브랜치에서 직접 브랜치를 만들어 필요한 부분만 수정한 후 다시 master 브랜치에 병합하여 이를 배포한다.

   배포한 버전에 긴급하게 수정할 부분 발생 -> master 브랜치에서 hotfix 브랜치 분기
   문제가 되는 부분 수정 후 master 브랜치에 merge하고 배포
   hotfix 브랜치에서의 변경 사항은 develop브랜치에도 merge한다.

pull request로 넘어감