사전 지식
•
작성 환경
•
Organization 계정의 Private Repository
•
브랜치 전략은 GitHub Flow
2. 일반적인 이슈 처리 프로세스
서비스를 운영하면서 발생되는 이슈에 대한 처리 프로세스는 아래와 같습니다.
1.
서비스 중 오류 발생 및 기능 개선 사항 도출
2.
이슈 등록
3.
이슈 담당자 배정
4.
이슈에 대한 버그/기능 개선 작업 진행
5.
개선 사항 서비스 반영
6.
고객에게 개선 사항 안내
7.
유사한 이슈 발생 시, 이전 이력을 확인하여 참고
3. Issue ?
깃허브에서 제공하는 이슈 트래킹 기능으로써, 프로젝트의 작업,
개선 사항 및 버그를 추적할 때 사용하기 좋습니다.
프로젝트 기획, 새롭게 추가될 기능, 버그와 수정사항 모든것을이 이슈라고 할 수 있습니다.
장점
•
이슈 등록 템플릿을 통하여 편리하고 일관성있는 이력 작성 용이함.
•
이슈 등록 시, 이슈 넘버 (#숫자)가 생기고, 이슈가 포함된 리파지토리 내에서
커밋 메시지에 이슈 넘버를 같이 등록하면 이슈 링크가 자동 생성되어 연결됨.
(기존 SVN에 지라 넘버를 포함하는 것과 동일)
•
이슈 등록 → 이슈 개선 → 코드 통합이 유기적으로 이루어짐
•
그리고 가장 중요한건, GitHub Web, App으로 모든 내용을 확인 할 수 있다!
1. 이슈 등록 방법
1.
이슈 접수
A 고객사에서 B 기능을 사용할 때 C라는 오류가 발생합니다.
Plain Text
복사
2.
이슈 등록
New issue 클릭
이슈 종류에 따라 기능 (Feature), 버그 (Bug) 템플릿 선택하여 Get started 클릭
템플릿에 이슈에 대한 내용을 기입합니다.
Assignees 의 경우 해당 이슈를 처리할 담당자를 의미합니다.
중요한 부분은 Projects 를 선택하는건데요,
해당 가이드에서는 Project Practice 를 선택하겠습니다.
내용을 모두 작성 후, Submit new issue 버튼을 클릭해주세요.
이슈가 잘 등록된것을 확인하였습니다.
이슈 제목에 #17 이라는 숫자가 해당 이슈에 대한 고유 번호라고 생각하시면 됩니다.
편의상 Assignees ( 담당자 )는 저로 설정했습니다.
3.
이슈 처리
작성자는 GitHub Flow라는 브랜치 전략을 이용하기 때문에,
해당 이슈에서 브랜치를 생성하도록 합시다
브랜치 명의 경우 디렉토리 구조로 작성합니다.
모듈 ? user, admin, core … etc
1. 버그 Fix Case
fix/모듈/기능
2. 기능 수정/추가 Case
feature/모듈/기능
해당 프로젝트의 로컬 리파지토리 경로 이동 후, 해당 경로에서 Git Bash를 열고
Github에서 알려준 명령어를 붙여넣습니다.
브랜치가 생성된 것을 확인하였습니다.
IDE에서 해당 프로젝트를 오픈하면,
신규 추가한 브랜치로 체크아웃이 되어 있는것을 확인할 수 있습니다.
문제가 있는 코드를 수정 후 Commit and Push
여기서 중요한 점은 커밋 메시지 작성 시 이슈 넘버 (#을 포함)을 추가한다.
Commit Message에도 Convention (규칙)이 있기 때문에, 그냥 막 쓰지말고 신경쓰기!
https://doublesprogramming.tistory.com/256
마스터 브랜치에 코드를 merge하기 위해서 Pull request를 날리자.
Reviewers 코드를 리뷰할 담당자를 지정
Assignees 작업자, 보통 본인을 지정
Labels 이슈 성격에 맞는 라벨을 선택
Projects 이슈가 등록되어 있는 프로젝트를 선택
내용을 모두 작성한 후 Create pull request 클릭
4.
코드 리뷰
리뷰어는 변경된 코드 및 기능 테스트 이후 코멘트를 통하여 피드백을 준다.
문제가 있는 경우, 관련 코멘트를 남긴 후 해당 PR을 Close 한다.
문제가 없다면, merge를 해도 괜찮다는 코멘트를 남긴다.
이 때, 리뷰어가 merge를 해줘도 되지만, 본인의 코드의 대한 책임감을 가질 수 있게,
마스터 브랜치에 merge는 작업자 본인이 하도록 하자.
5.
PR 코드 머지
Merge pull reqest → Confirm merge
이 때, 브랜치에서 수정한 코드와 마스터 브랜치의 코드가 충돌날 경우,
merge를 진행 할 수 없고, 브랜치 코드 쪽에서 충돌이 나지 않게 수정 후
merge 하도록 하자
merge 가 된 브랜치는 삭제하도록 하자.
공공메일 서비스 리파지토리 ( gov-webmail )은 자동으로 삭제가 되도록 설정 되어 있음.
merge 가 된 이후 해당 PR의 우측을 살펴보면
Project 에 등록된 해당 아이템의 상태가 Done으로 변경되었고,
관련 Issue 또한 해결 됨을 확인 할 수 있다.
리파지토리 내 Issues 탭을 클릭 후 Closed를 선택하면
해당 이슈가 종료됨을 확인할 수있다.
4. Project ?
깃허브에서 제공하는 프로젝트 관리 기능으로써, 작업의 진척도 및 이슈 트래킹 등 프로젝트의 전반적인 상황을 한 눈에 볼 수 있습니다.
프로젝트 내 할 일의 진행 상태 및 이슈에 대하여,
칸반보드, 테이블, 타임라인 등 다양한 레이아웃을 통하여 한눈에 볼 수 있습니다.
따라서, 이슈 등록 시, 프로젝트를 선택해야 해당 프로젝트에서 해당 이슈를 확인할 수 있다.
프로젝트 내 커스텀 필드 사용 방법
프로젝트 → … → Setting 클릭
Field name : 필드 이름 지정
Field type : 필드의 종류를 선택
필드 추가가 완료 되었다면 Save 클릭
프로젝트에서 아이템 (할 일, 이슈)에 대하여 커스텀 필드 설정을 할 수 있다.
프로젝트에서 제공하는 레이아웃 모두에서 커스텀 필드가 적용된 것을 확인할 수 있다.