#5 Github에서의 Issue관리

Github에서의 Issue 부분

Issue
 : Task 또는 Bug Report의 역할을 함
 : 개발로 이어진다면 Branch로 이어짐

Lable
 - Issue의 종류를 구분하는 일종의 태그
 - 하나의 이슈에는 여러 개의 레이블 지정 가능

Milestone
 - 업무의 어떤 시점(원하는 시점)
 - 프로젝트 전체 기간의 타임라인이 존재
  : 어떤 일을 진행 = Step
   > Step에 대해서 특정 업무가 마무리 되어야하거나, 어떤 문서가 나와야하는 등의 목표가 존재
   > 일을 진행하는 이정표 = 마일스톤
  : 특정 지점(이정표) = 마일 스톤
   > 기능 등이 완성되어야 하는 시점
   > 업무의 마감일
   > 일들의 우선 순위를 판단할 수 있음

Github Milestone생성

 - Github Milestone
 : 제목
 : 마감일 = 타임라인의 특정 시점을 의미
 : 설명

예시

 - Issue를 너무 크게 잡았을 경우 분할 > 마일스톤을 기점으로 분할 
 
마일스톤과의 비교
1) 목표 VS 마일스톤
 - 목표 : 앞으로 달성하고자 하는 것
 ex) 목표: 전자책 홍보
 - 마일스톤
  : 이미 달성한 단계를 되돌아보기 위한 것
  : 목표를 달성하기 위해 필요한 사다리의 각 발판
 ex) 마일스톤: 색상 선택 | 디자인 템플릿 생성 | 출시 계획 승인

2) 프로젝트 단계 VS 마일스톤
 - 프로젝트 단계
  : 프로젝트 단계(개시, 계획, 실행, 종료)의 시작이나 완료와 맞물림
  : 프로젝트 단계 -> 수행 기간 포함
 - 마일스톤
  : 주요 진행 상태를 나타내는 체크 포인트 
  : 기간은 중요하지 않음

3) 프로젝트 결과물 VS 마일스톤
 - 프로젝트 결과물 : 제품
 - 마일스톤
  : 시점
  : 결과물이 있을 수도, 없을 수도 있음
  : 결과물이 존재 = 마일스톤의 완료를 의미

4) 작업 VS 마일스톤
 - Step은 작업(Task)들의 집합
 - 작업(Task)
  : 프로젝트의 구성 요소
  : 시간 소요
 - 마일스톤
  : 일련의 작업들 사이의 경계선

Issue 생성
1) Issue 작성
- 제목과 내용 기술
 > Markdown으로 기술
- 부가 정보
 > 할당(일을 수행할 사람)
 > 레이블 (Bug report 등등..)
 > 마일스톤 등

2) Issue생성 시
- 번호가 붙음(#n)
- 개발 시 Commit 메시지에서 번호를 통해 언급 가능

3) Issue 종료
- Close as Completed
 : 완료
 : 수정 및 개발 진행시 사용
- Close as not planned
 : 계획 없음
 : 개발 예정 없는 경우 사용

4) Github Issue
- 같이 개발하는 모든 참여자가 작성 가능
- 개발 뿐 아니라, 기획 단계에서부터 사용을 고려하여 개발의 전 과정을 추적하기 위한 용도로 사용 가능
 > Issue = 기록역할 > 개발 수행은 Branch를 통해 진행 > 개발 완료후 Branch Remove > 기록(Issue)
 > Branch는 최종 결과가 Merge되어 Main Flow에 반영되고 Remove되지만, Issue는 Closed의 형태로 남아있음
- 개발 후에는 제품의 버그 등의 결함을 보고 받고, 개선하는 과정을 추적하기 위한 용도로 사용

Github Wiki
- 문서의 공유
 : 개발자가 아닌 직무의 사람들과 공유 = Wiki

- 개발자간 공유
 > Github Repository 내에서 *.md  파일을 통해 공유 가능
- 비개발자와 공유
 > Github Wiki를 사용하여 공유

Wiki, *.md 파일
 : Github에서 Markdown의 렌더링을 통해 표현
 : 개발에 참여하는 사람들과 최신의 문서를 공유
 : 필요한 경우, 문서를 자동으로 생성하고 배포할 수 있어야 함