Issue 발행
- 새로운 추가될 가능, 개선 해야할 가능, 버그 등등 모든것이 이슈
- 활동 내역에 대해서 이슈를 등록하고 그 이슈기반으로 작업을 진행
- Issue Template 파일을 등록하여 사용하면 효율적
Issue 작업
- Assignees : 해당 작업의 담당자
- Labels: 해당 작업의 성격
- Milestone: 해당 작업이 속한 파트
Github 이슈 기반으로 Branch를 생성?
Github Issue는 각자의 유니크한 값인 Issue Number를 갖습니다. 또 그 Iusse Number 기반으로 Branch를 이름을 갖게 하여 해당 Branch의 명확한 작업의 의도를 갖게 할 수 있습니다.
Branch 네이밍을 통해서 해당 작업의 의도를 갖게 하는 것은 한계가 있습니다. 또 동료 개발자들이 정확히 무슨 작업을 하는지도 Branch 네이밍을 통해서 유추해내기도 어렵고, 해당 작업이 반영(머지)될 때 도 마찬가지입니다. 이러한 문제들을 Issue Number 기반으로 Branch를 생성(Issue Number Branch 네이밍에 추가)하면 아주 명확해집니다.
- 작업후 PR
- Reviewers 톱니바퀴 버튼을 클릭해서 리뷰어를 지정합니다.
- resolved 키워드를 입력하면 해당 풀리퀘스트가 main에 반영되면 자동으로 close
- 자동으로 close 되는 것이 싫다면 issue: #[해당 Issue Number]를 작성
- 키워드 없이 PR이 생성되면 새로운 Issue Number가 부여, 즉 Pull Request도 Issue
- 키워드로 이슈를 연결하면 이슈에서도 pr
resolved: #1(해당 Issue Number) 풀리퀘스트 요청하는 이유 즉 무슨 이슈에 대한 작업인지 명시
작업흐름
- 필요한 작업을 issue에 등록한다.
- 등록된 issue가 자동으로
To do에 생성된다.
- 작업을 시작하려는 issue를
In progress로 옮긴다.
- 로컬에서 feature 브랜치를 생성해 코드 작업 후 원격 저장소에 Pull request를 날린다.
- 코드 리뷰를 받고 approve되면 develop 브랜치로 병합한다.
- 해당 feature 브랜치를 삭제한다.
- issue를 닫으면 In progress에서 자동으로
Done으로 옮겨진다.
작업 상태
- To do : 할 일들 중 아직 작업이 시작되지 않은 상태를 나타낸다.
- In progress : To do 목록에서 이동되며 시작된 작업들을 나타낸다.
- Done : In progress에서 코드리뷰를 마치고 develop 브랜치에 병합된 작업임을 나타낸다.
참고글
