[GitHub] issues는 무엇이고 어떻게 사용하는걸까??

 

 

프로젝트를 진행하면서 깃허브에서 버전 관리를 하고 있다.

그런데 다른 사람들의 레파지토리를 구경하다 보면 issues 카테고리에서 사람들이 글을 올리는 것을 확인할 수 있는데,

대체 이것이 무엇인가..!! 궁금해서 찾아보고 정리해보기로 했다~

 

issue의 사전적 의미는 논쟁, 논점이라는 것인데 즉 프로젝트를 진행하면서 발생한 논쟁할 것이라고 생각한다.

모든 소프트웨어 프로젝트는 작업을 추적(track)하고 구성(organize)하는 방법이 필요하다. → GitHub issues 사용

 

 

 

📌 GitHub Issues는 무엇인가~ 

 

먼저 간단히 말하자면, 프로젝트를 진행하면서 발생하는 모든 issue를 뜻한다.

모든 GitHub 레파지토리에서 사용 가능한 가벼운 이슈 추적 시스템(lightweight issue-tracking)이다.

레파지토리를 만들면 issues를 바로 사용할 수 있고, 프로젝트를 진행하면서 계속 사용하게 된다.

나는 그동안 issues가 뭔지도 모르고 commit, push 하기에 바빴기 때문에 (반성하자^^...) 텅 비어있다.

위에 적혀있는 것을 보니

 

"Issues는 작업관리, 버그, 기능 요청 등을 추적하기 사용된다. issues가 생성되면 검색 및 필터링 가능한 리스트에 issues가 표시된다."

 

그러니까, GitHub Issues는 버그를 보고하고 기능을 요청하는 데 사용된다. 

유저 피드백 모으기, 버그 보고, 레파지토리 내의 이슈들을 해결하고 싶은 작업을 관리하는 데 사용할 수 있다.

pull request를 issue에 연결해서 수정이 진행 중임을 알릴 수 있고, 자동으로 다른 사람이 pull request를 병합(merge)할 때 issue를 닫을 수도 있다.

 

즉 Issues 기능은 프로젝트에서 발생하는 모든 문제를 관리할 수 있도록 하는 것이다. 깃허브는 협업을 도와주는 툴이니~

 

 

---

 

이제 이 Issue를 사용하는 방법에 대해서 알아보자.

 

📌 Issue 생성하기

 

이슈는 레파지토리를 생성하면 Issues 카테고리를 확인할 수 있는데, 해당 카테고리로 들어가서

New issue 버튼을 클릭한다. 

issue에 대한 제목과 내용을 작성할 수 있다. 내용은 마크다운으로 작성하고 Preview 탭을 누르면 마크다운이 적용된 텍스트를 미리보기로 볼 수 있다.

Submit new issue 버튼을 누르면 해당 이슈를 제출할 수 있는데 이렇게 생성된 이슈들은 리스트 형태로 나타난다.

그런데 이슈가 굉장히 많아지면.. 관리하기 힘들어지지 않을까? 아래의 기능을 사용하면 분류, 관리하기 좋다!

 

 

📌 기능

 

- Label 기능

각 이슈에 대해 라벨링을 해서 이슈를 검색할 수 있고 이슈별로 주제를 구분할 수 있다.

새로운 라벨도 만들 수 있고, 기본으로 있는 라벨을 사용할 수도 있다.

나누는 기준 → 우선순위, 카테고리, 정보를 나누는 기준 (작은 단위일수록 좋다)

 

- Assignees 기능

해당 이슈에 대한 책임자 부여

 

 

한번 issue 테스트를 해봤다.

이렇게 지정한 라벨과 책임자(assignee)를 통해 Filters에서 이슈 검색할 수 있다

 

 

- Milestone 기능

이정표 역할을 하고, 이슈들을 그룹화한다.

이슈는 reopen, close(이슈가 해결되면 문 닫아 close)를 할 수 있고 마일스톤으로 최대 3개까지 묶을 수 있다.

 

 

---

 

 

만약 레파지토리에 issues를 오랫동안 사용하고 생산성을 유지하고 싶다면 기본 관행을 따르면 좋다.

지금부터 그 관행을 살펴보자.

 

 

01. 중복을 피하기 위해 검색해보기

새로운 이슈를 제출하기 전에 이미 존재하는 이슈를 검색해보자. 시간 절약

 

이슈를 작성하려던 사람은 제출 전에 검색함으로써, 이미 비슷한 이슈 존재하면

- 해당 이슈의 상태에 대해 업데이트할 수 있다.

- 영향을 받는 다른 사용자나 프로젝트 팀이 설명했을 수 있는 해결 방법에 대해 배울 수 있다.

- 문제를 설명하는 데 시간을 할애하지 않아도 된다.

 

프로젝트 유지 관리자는 

 

- 문제를 분류하는 데 걸리는 시간을 절약

- 특정 문제에 대한 작업을 한곳에서 알릴 수 있는 모든 관련 사용자 피드백을 얻을 수 있다.

 

 

02. 이슈 보고할 때 structure 추가하고 최대한 구체적으로 작성하기

레파지토리에서 이슈를 보고하면 받아들일 준비가 된 문제와 해당 문제에 포함할 정보의 종류를 정확하게 정의해야 한다.

이를 위해 GitHub Issues에서는 이슈 템플릿을 제공한다. 설정을 변경하면 사용할 수 있다.

 

 

 

03. 라벨 사용하기

위에서도 말했지만 라벨을 사용하면 각 이슈를 분류하기도 좋고 검색하기도 편리할 뿐더러 팀 작업을 관리하기 쉽게 분리할 수 있다.

 

- 책임 별로 프로젝트를 세분화하기: 프로그램의 구조에 따라 개별 구성요소 또는 하위 시스템에 대한 라벨을 사용할 수 있다.

- 분류되지 않은 이슈 표시하기: 팀이 모든 새로운 이슈를 분류하기 위해 라벨을 사용하여 새로운 이슈에 적용할 수 있다. 그런 다음 이 라벨이 있는 모든 이슈를 검색하고 문제를 처리되면 해당 레이블을 제거해야 합니다. 분류 제목으로 표시된 이슈를 검색해도 아무것도 반환되지 않는 경우 모든 이슈를 올바르게 분류했음을 의미한다.

- 추가 정보를 기다리는 이슈를 제출자로부터 격리하기: 이슈에 대한 세부 정보가 부족한 경우, 제출자에게 세부 정보를 요청하고 추가 정보 필요와 같은 특수 레이블을 설정할 수 있습니다. 제출자가 특정 시간 내에 세부 정보를 제공하지 못하면 요청을 완료되지 않은 것으로 닫을 수 있습니다(!)

 

 

04. 관련자, 책임자 언급하기

다른 사람의 전문 지식을 활용하고 싶거나, 견적을 제공받거나, 이슈를 인지하고 싶다면 다른 사람을 언급하자.

 

- 언급할 때마다 언급하는 사람에게 전자 메일 알림이 전송되므로 언급은 조심히.

- 전에는 이슈에 관여하지 않았던 사용자를 언급할 때는 해당 사용자에게 수행할 작업이 있는지 또는 진행 상황을 알리는 작업인지 명확히 해야 한다.

 

 

05. 이슈 해결 시, 꼭 close 해주기

이슈가 해결되었는데 계속 open 해두면 사용자는 자신이 요청한 변경 사항을 인식하지 못한다. 개발자의 경우, 모든 추가적인 공개 이슈는 다음에 무엇을 해야 하는지 결정하는 것을 어렵게 한다.

 

 

 

---

📌 Conclusion

 

issues에 대해서 알아봤는데 협업 툴을 사용하는 이유를 알게 해 준...

버전 관리뿐만 아니라 사람들과의 커뮤니케이션을 위해 꼭 필요한 기능이라고 생각한다. 개인 프로젝트여도 사용하면 너무 좋을 거 같다.

진작 알았어야 했는데 아쉽다.

 

 

 

 

 

참고

⭐️ https://yagom.net/forums/topic/github-issue-사용하기/

Github Issue 사용하기 - 야곰닷넷

https://rewind.com/blog/best-practices-for-using-github-issues/

Best Practices for Using GitHub Issues - Rewind