[ Github ] - Github Issue, 프로젝트 개발 과정을 잘 남기는 법

 

이슈(Issue)를 만드는 경우

히스토리를 관리해야 할 모든 과제에 대해 만들면 좋다.

 

1. Feature (기능)
2. 버그 / 크래시
3. 구조 / 성능적인 문제
4. 프로젝트와 관련된 다른 팀과 한 논의 내용
5. 프로젝트 모니터링 결과
6. 프로젝트 개발 회고

---

이슈(Issue)에 적을 내용

이슈를 해결하기 위한 히스토리

 

1. 문제 이슈 업
2. 문제 해결 및 논의
3. 추가적인 문제
4. 문제 해결 및 논의
5. 해결
6. ... 
7. 이슈 완전 해결 --> close

이슈 라벨(Label)

위의 이슈 항목에 따라, 라벨을 만들어 표시한다. 

이슈 라벨

---

이슈(Issue)와 커밋(Commit) 연동

Commit 메세지에 "#[issue number]"를 입력하면, 이슈와 커밋이 연동되며, 자동으로 이슈에 커밋 내용이 추가 된다.

커밋

 

커밋과 함께 이슈를 Close 할 수 있는 Keyword

이슈를 해결 했을 때, 이슈를 Close 해야 하는데, Commit 메세지에 적절한 키워드를 사용하게 되면, 이슈를 자동으로 Close 시킬 수 있다.

 

Keywords

• close
• closes
• closed
• fix
• fixes
• fixed
• resolve
• resolves
• resolved

예시

커밋 연동

git commit -m "[#1] 1번 이슈와 커밋 연동" // 1번 이슈에 대한 커밋이라는 뜻

커밋 자동 Close

git commit -m "fix [#1] - 1번 이슈에 대한 버그 수정"

 

Feature 이슈를 생성하는 기준

분리될 수 있는 작업 단위

• 화면 단위 or 화면 내 기능
• 큰 기능 -> 작은 단위
• 레이어 단위 ( ui - domain - data )
• 개념적으로 나눠지는 작업 단위
• ...

> 1~5일 동안 작업할 수 있는 양이 적당

 

---

Feature 이슈 생성시 내용

• Feature 기획 내용 (화면 , 기능 등)
• Feature 구현 시 관련된 기술적인 내용
• 구현할 내용에서 고민해야할 부분

이 정도만 작성해두고, 구체적인 설께나 작업은 Feature 개발을 시작할 때 고민

---

Feature 개발 시작 시

• Feature를 개발하면서 발생한 모든 사항을 기록
• 고민되는 부분, 막힌 부분, 참고할 만한 부분
• 핵심은 내가 여기서 해당 이슈를 스탑하더라도, 나중에 다시 이슈에 적은 내용만 보고, 작업을 이어할 수 있어야 함