Github / Issue Tracker와 Project Board

불꽃남자·2021년 6월 27일
github
8

포스트 작성 계기

깃허브를 접하고 사용한 지도 1년이 다 되어간다.
그런데 아직 깃허브를 사용한 팀 단위의 개발을 접해보질 못 해서 깃허브로 하는 거라곤 Commit이랑 어줍잖은 Branch와 Merge뿐이다. 사실상 코드 저장소 정도로 사용하고 있었다.
잘 모르지만서도 어렴풋이 느끼기엔 깃허브를 잘 못 사용하고 있다고 느껴져 구글링으로 배우게 된 것이 Issue Tracker 기능과 Project Board 기능이다.

Issue Tracker

깃허브 레포지토리 탭 메뉴를 보면 Issue라는 메뉴가 있다.
이전에는 그냥 "프로젝트를 배포한 뒤, 사용자들이 그에 대한 버그나 건의사항을 적는 곳" 정도로 인식하고 있었는데, 그건 Issues의 기능 중 하나였고 더 많은 기능을 가지고 있었다.

Issue의 명사로써의 사전적 의미는 다음과 같다.

  1. (논의논쟁의 중요한) 주제[안건], 쟁점, 사안
  2. (걱정거리가 되는) 문제

내가 생각했던 Issues의 기능은 2번의 의미로써 뿐이었고, 사실은 더 나아가 1번의 의미로써의 기능까지 제공하고 있었다.

좀 추상화시켜 이야기하자면 현재 내가 생각하는 Issues의 가장 주요한 기능은 TodoList로써의 기능이다.

사용법

이 개념을 처음 접할 때 글만으로는 이해하기 힘드니 사진과 함께 알아보자.

1

처음 Issues 메뉴를 열어보면 이런 화면이다. New Issue 버튼으로 새 Issue를 만들어보자.

2

짠, 새로운 이슈를 만드는 화면이다.
UI를 살펴보면, 일단 이슈의 제목과 본문을 입력한다. 본문은 마크다운으로 입력할 수 있고 마크다운 도구도 지원된다.

그리고 오른쪽에 있는 메뉴가 핵심이다. 하나하나 살펴보자.

Assignees

Assignees는 이 이슈를 처리해야할 담당자를 지정하는 메뉴다.
3
혼자 하는 프로젝트라 나 밖에 없는게 어쩐지 쓸쓸하다.

Labels

이 부분이 중요하다.

이슈를 하나 둘씩 등록하다보면 제목만으로는 이슈들의 구분이 힘들어져서 우선순위, 혹은 이슈를 해결해야할 역할군을 지정하기가 힘들어진다. 프로젝트가 오래되었고 규모가 크다면 이슈가 2000개, 10000개씩 쌓이는 일도 있다.

그래서 이슈에 Label을 붙여서 구별이 용이하게 만드는 것이다.
4

깃허브가 기본으로 등록해놓은 9개의 Label들이 있고, 맨 밑의 Edit labels 버튼으로 사용자 정의 Label을 만들 수 있다.

Projects

5
처음으로 이걸 열어봤다면 아무 것도 없을 것이다. 나는 General Board라는 이름의 Project Board를 만들어 놓아서 목록에 있다.

Projects 메뉴는 해당 이슈를 어느 Project Board에 놓을 지 정하는 메뉴다.

Project Board에 대해선 아래에서 마저 설명할 것이다.

Milestone

6
이 메뉴도 Projects와 마찬가지로 처음 열면 아무것도 없다.
Milestone 메뉴는 해당 이슈를 어느 Milestone에 포함시킬 것인지 정하는 메뉴다.

Milestone은 간단히 말하자면 여러 개의 이슈를 포함하는 이슈의 상위 개념이다. 이 또한 아래에서 자세히 설명하겠다.

이슈 등록

이제 이슈를 등록해보자. Submit new issue 버튼을 누르면 등록된다.
7
와우! 이슈가 등록되었다. 등록된 이슈들은 Issues 탭 메뉴에 등록된 순서대로 쌓인다.
이슈 리스트 상단에는 이슈들을 필터링 할 수 있는 메뉴도 제공되어 있어 이슈들을 일목요연하게 볼 수 있다. 이슈가 많으면 많을 수록 빛을 발하는 기능이다.

이슈를 등록했으니 이 이슈를 해결하는 법에 대해서도 알아보자.

이슈 닫기

이슈를 열어보면 번호가 붙어 있는 걸 볼 수 있다.
8
이 이슈는 #4 라는 번호가 붙어 있다.

이슈에 관한 작업을 하고나서 이슈 아래에 해당 커밋을 나타나게 하고 싶으면, 커밋을 할 때에 커밋 제목에 해당 이슈의 번호를 붙여주면 된다.
이것을 Issue linking이라고 한다.

9
여기 #2 이슈에 관한 코드가 담긴 커밋이 있다. 제목에 #2 를 붙여놓았는데, 이 부분에 링크가 생겼고 마우스를 올려보면 해당 이슈의 요약정보가 나타난다.

10
클릭해보면 해당 이슈 페이지로 이동하고, 이슈의 타임라인에 해당 커밋이 추가된 것이 보인다.

이제 이슈를 닫는 방법에 대해 알아보자.

이슈를 해결하는 행위를 Github에선 Close issue 라고 한다. 이슈를 닫는다 라고 해석하겠다.
이슈를 닫기 위해선 일반적으로 두 가지 방법을 사용하는데,

  1. 이슈 페이지 맨 아래에 있는 Close issue 버튼을 누른다.
  2. 커밋할 때에 닫고자 하는 이슈의 번호와 함께 접두사를 붙인다.

가 그 두가지 방법이다.

Close issue 버튼 누르기

11
이슈 페이지 맨 아래를 보면 Close issue 버튼이 있다. 이걸 누르면 이슈가 닫힌다.

커밋 제목에 이슈 번호와 함께 접두사 붙이기

Github Docs에 가장 자세히 나와있다.

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

이 9가지 단어 중 하나를 Issue link의 앞에 붙이면 해당 이슈에 Issue linking 됨과 동시에 Issue closed 된다.

KEYWORD와 #ISSUE_NUMBER가 커밋 제목에 포함되어 있으면 인식되는 모양이다.

다만, 올바른 문자열이 커밋 제목에 포함되어 있어도 레포지토리의 default branch에 커밋된 게 아니라면 이슈 링킹은 작동하지 않는다.
또한 다른 branch에서 커밋되었더라도 해당 커밋이 default branch로 merge되면 이슈 링킹이 작동한다.

Linked issueSyntaxExample
Issue in the same repositoryKEYWORD #ISSUE-NUMBERCloses #10
Issue in a different repositoryKEYWORD OWNER/REPOSITORY#ISSUE-NUMBERFixes octo-org/octo-repo#100
Multiple issuesUse full syntax for each issueResolves #10, resolves #123, resolves octo-org/octo-repo#100

Github Docs에 의하면, 다른 레포지토리에도 이슈 링킹이 가능하며 하나의 커밋을 여러개의 이슈에 링킹하거나 닫는 것이 가능하다.

fix #11, #13, #17 같이 커밋 제목을 작성해도 #11, #13, #17 이슈가 전부 닫히는 것 같다.

Project Board

Project Board는 기본적으로 칸반 보드 레이아웃을 가지고 있다. 이 안에는 이슈들에 대한 전체적인 진행 상황이 담겨 있고, 진행 상황을 컨트롤 할 수 있다.

사용법

12
Projects 페이지에서 New Project 버튼을 누르면 이런 화면이 된다.
Project의 제목, 설명을 입력하고 Project template를 선택한 뒤 Create Project 버튼을 누르면 Project가 생성된다.

13
Project template는 이것저것 있지만, 1인 프로젝트에 적합하다고 생각되는 Automated kanban을 선택했다.

14
짠, 멋지게 생긴 Project Board가 완성됐다. 사용법을 잘 알고 사용하면 개발 효율에 있어 굉장한 이점이 있으니(1인 프로젝트라 할지라도) 하나하나 알아보자.

먼저 가장 큰 부분을 차지하는 To do - In progress - Done 으로 구성된 Board 부분을 보자. 이런 레이아웃을 칸반 보드라고 한다.

이 칸반 보드는 현재는 세 Column으로 나뉘어져 있는데, 사용자가 원한다면 Add Column 버튼을 눌러서 새로운 Column을 계속 만들 수 있다.

Column 안에는 여러 개의 Card가 포함되고, Card는 왼쪽 Column에서 오른쪽 Column으로 이동된다. 일반적으로 맨 왼쪽에 TodoList Card가 들어오고, 해당 Todo Card에 대한 개발이 이루어지고 있으면 In progress Column로 카드를 옮기고, Todo Card가 해결되면 Done Column으로 옮긴 뒤 종결한다.

Card는 Note card와 Issue card, Pull request card로 구분된다.

Note card

Note card는 Column의 위에 있는 + 버튼을 눌러 해당 Column에 추가할 수 있다.
15
화면의 Todo column을 보면 Project를 만들면 자동으로 추가되는 Note Card들도 보인다.

Issue card

그리고 화면 오른쪽을 보면 슬라이드 메뉴 안에 Issue card가 있다.
기본적으로 모든 이슈들을 선택할 수 있고, Qualifier를 통해 Issue를 검색할 수 있다. Qualifier에 대해선 Github Docs의 해당 항목을 살펴보라.

화면에선 is:open Qualifier로 현재 열려있는 이슈들만 보여진다. 이 Issue card를 클릭 후 드래그해서 Column으로 옮길 수 있다.

16
이렇게 말이다.

이후 개발 진척도에 따라 Card를 다른 Column으로 이동시켜주면 된다.

Pull request card

이 레포지토리에서 Test branch를 분기해서 Test Commit을 main branch에 PR했다.
17
화면 오른쪽 메뉴를 보라. Test Commit PR card가 생겼다.

이 또한 Issue card와 마찬가지로 개발 진척도에 맞게 Card를 옮겨주면 된다.

Automate manage

각 Column의 아랫쪽을 보면 Manage 버튼이 있다.
Card가 자동으로 등록되고 이동하는 것을 Manage하는 옵션이다.

일단 버튼을 클릭해보자.

18

첫 번째로 Preset이다. 현재는 To do로 선택되어 있는데 클릭해보자.

19

Preset은 해당 Column이 어떤 Automate preset을 사용할지에 대한 Preset이다.

  • To do: 할 계획이지만 아직 시작되지 않은 Card가 있는 Column에 대한 Preset이다.
  • In progress: 현재 처리하고 있는 Card가 있는 Column에 대한 Preset이다.
  • Done: 완료된 Card가 있는 Column에 대한 Preset이다.
  • None: 어느 Automate 옵션도 사용하지 않을 Column에 대한 Preset이다.

앞서 Project를 생성할 떄에 Template를 선택하던 것이 기억나는가? 선택한 Template에 따라 적절한 Automate 옵션이 설정된 Column들을 자동으로 생성해준다.

To do

20
To do Preset의 옵션부터 살펴보자.

  • Move issues here when...
    • Newly added: 이 프로젝트에 이슈가 등록되면 이 Column에 해당 이슈 Card가 등록된다.
    • Reopened: 이 프로젝트에서 닫혔던 이슈가 reopen되면 이 Column에 해당 이슈 Card가 등록된다.
  • Move pull requests here when...
    • Newly added: 이 프로젝트에 Pull request가 발생하면 이 Column에 해당 Pull request card가 등록된다.
    • Reopened: 이 프로젝트에서 닫혔던 Pull request가 reopen되면 이 Column에 해당 Pull request card가 등록된다.

현재 프로젝트에서는 Reopened 옵션을 In progress column에서 사용하고 있기 때문에 To do column에서 선택이 되지 않는 모습이다.

In progress

21

처음 나온 옵션만 설명하겠다.

  • Move pull requests here when...
    • Approved by reviewer: 해당 Pull request card가 최소 필수 Approving review를 충족하면 이 Coulmn에 자동으로 등록된다.
    • Pending approval by reviewer: 해당 Pull request card가 최소 필수 Approving review를 충족하지 못 하거나, Request changes(Pull request 거절)되면 이 Coulmn에 자동으로 등록된다.

적혀있기로는 Approved by reviewer 옵션과 Pending approval by reviewer 옵션은 서로 다른 Column에서 각각 활성화 시켜놓는 것을 권장하고 있다.
승인된 Pull request와 거절된 Pull request를 분리시키고 그에 따른 적절한 절차를 적용하기 위한 것으로 생각된다.

Done

22

  • Move issues here when...
    • Closed: 해당 Issue card가 닫히면 이 Column에 자동으로 등록된다.
  • Move pull requests here when...
    • Merged: 해당 Pull request가 Merge되면 이 Column에 자동으로 등록된다.
    • Closed with unmerged commits: 해당 Pull request가 Merge되지 않은 채로 닫히면 이 Column에 자동으로 등록된다.

Milestones

마지막으로 알아볼 메뉴는 Milestones이다. Milestone은 말 그대로 이정표인데, Issue보다는 크며 Project보다는 작은 개발 단위 라고 생각한다.

일단 만들어보며 알아보자.

사용법

23

Issues 혹은 Pull requests 페이지의 상단을 보면 Milestones 메뉴가 있다. 페이지에 진입하면 이런 모습을 하고 있다. 새로운 Milestone을 만들어 보자.

24

제목과 설명, 그리고 마감일을 정할 수 있다. 마감일은 optional이다.

25

Milestone이 만들어졌다.

Milestone에는 Issue들이 등록되는데, Issue를 만들 때에 해당 Issue를 어느 Milestone에 등록할지 정할 수 있다. Issue를 등록하러 가보자.
26
Milestones 옵션을 열어보면 방금 만든 Milestone이 있다.
Issue를 등록할 때에는 두 개 이상의 Milestone을 지정할 수 없다.

이 Milestone로 지정하고 Issue를 등록해보자.

27
짠, Milestone에 Issue가 등록되었다. 이렇게 Issue를 만들 때 마다 관련된 Milestone에 등록해서 특정 기능에 대한 Issue들을 한 곳에 모아 볼 수 있다.

그리고 Milestone에 등록된 Issue가 닫히면 Milestone의 진척도가 올라간다. Test Issue를 닫아보자.

28
Issue가 총 1개 등록되었는데 1개가 닫혀서 진척도가 100%가 된 모습이다.

🍉

이번 포스팅에선 Github의 레포지토리 기능 중 Issue tracker, Project board, Milestone에 대해 알아보았다.

전체적으로 체계적인 개발을 도와 개발 효율을 높여주는 역할을 한다.
이것이 팀에서 사용된다면 프로젝트의 진척도, 마감일 등을 가늠하며 팀원 개개인의 어떤 역량등을 점쳐볼 수 있을 것이고, 1인 프로젝트에 적용된다면 개발 동기를 부여하며 개발에 대한 긴장감을 유지할 수 있는 장치가 될 것이라 생각한다.

이런 좋은 기능들이 있는데 도대체 왜 여지껏 알아보지도 않고 사용하지도 않았는지 억울한 마음까지 든다. 늦었지만 지금이라도 알아서 다행이지 않은가.

이 포스팅을 쓰면서 Pull Request에 대해서도 알게 되었고, Git에 대해 여러가지 알게 되었다.
Git Hook이라는 것도 접했는데, 얼핏 보기로는 Issue Tracking이나 Commit에 대한 부분을 자동화 시켜주는 기능을 하는듯 하다. 이에 대해서도 포스팅을 할 예정이다.

그럼 다들 Github를 잘 활용해서 즐거운 개발을 하기 바란다. 안뇽~

profile
불꽃남자
프론트엔드 꿈나무, 탐구자.
이전 포스트

vue3에서 전역 변수 선언하기

다음 포스트

Github - merge / squash merge / rebase merge

0개의 댓글