본문 바로가기
GitHub

GItHub의 Issue와 Projects 완벽하게 활용하기!

by huffpuffkin 2025. 12. 29.

1️⃣ Issue

해야 할 작업/문제 하나를 기록하는 티켓

  • 버그, 기능 추가, 개선 사항 등을 적어두는 공간
  • 댓글로 논의하고, 담당자와 라벨을 붙일 수 있음
  • 즉, 작업의 최소 단위!

✔  PR

코드를 이렇게 변경했는데, 합쳐도 될까요?

  • Issue를 해결한 코드 변경 제안
  • 코드 리뷰, 코멘트, 수정 요청 가능
  • 승인되면 보통 main/dev 브랜치에 병합됨

✔  Milestone

특정 시점이나 버전까지 끝내야 할 작업 묶음 

  • 진행률(%)이 자동으로 보임
  • 일정/단계 관리용 

✔  Projects

Issue와 PR을 모아서 흐름으로 관리하는 보드

  • To do / In progress / Done 같은 칸반 보드
  • 여러 레포의 Issue/PR도 한 번에 관리 가능
  • 전체 작업 흐름 & 우선 순위 관리 

 

 

 

😄 정리하자면 

  • Issue: 할 일 하나
  • PR: 그 할 일을 해결한 코드
  • Milestone: 할 일 묶음의 목표 시점
  • Projects: 할 일들이 어디까지 왔는지 보는 판

 

📍실제로는 이렇게 활용할 수 있다!

1. Issue를 생성한다.

2. Issue를 Milestone v1.1에 포함한다.

3. Issue를 Projects의 To do에 올린다.

4. 코드 작업 후 PR을 생성한다. → Issue 연결하기!

5. PR을 리뷰 후 머지한다. → Issue 종료, Projects에서 Done으로 이동

 

 

 

📍버전은 어떻게 관리할까?

Semantic Versioning

구분 의미 예시
MAJOR 큰 변경, 깨지는 변경 v2.0
MINOR 기능 추가 v1.1
PATCH 버그 수정 v1.0.1

 

 

일반적 규칙

  • 첫 버전은 0.1.0으로 시작한다.
  • 소프트웨어가 실 서비스에 사용되는, 사용자들이 믿고 쓸 수 있는 안정적인 상태라면 1.0.0이 될 수 있다.
  • 특정 버전을 배포하고 나면 그 버전의 내용은 절대 변경하지 말아야 한다. 변경 사항이 있다면 반드시 새로운 버전으로 배포하도록 한다.
  • Major 버전이 변경될 때 Minor, Patch는 0으로 초기화한다.
  • Minor 버전이 변경될 때 Patch는 0으로 초기화한다.

 

단계 중심 버전

기획이 자주 바뀌는 초기 프로젝트에서는 단계 중심으로 구성해볼 수도 있다. 

버전보다 목표 중심으로 구성해주면 된다. 

  • MVP
  • Phase 1
  • 1차 배포
  • 기본 기능 완성

📌 예시

  • MVP
    • 로그인
    • 좌석 선택
  • Phase 2
    • 결제

 

 

 


📍Issue 라벨 & 템플릿 설정하기

레포지토리의 Settings > General > Features > Issues을 보면 아래와 같이 Set up templates 버튼이 있다. 

 

 

 

 

Add template 버튼을 클릭해 Custom Template을 선택해준다. 

 

 

 

 

그리고 확인해보면 다음과 같이 새로운 이슈 템플릿이 생성된 것을 볼 수 있다. Preview and edit을 선택해 커스텀 해주면 된다.

 

 

 

 

나는 Feature, Enhancement, Refactor, Bug, Deploy 이렇게 5가지로 구분해주었다. 

 

 

 

 

커스텀 이슈 템플릿을 작성하다보면 이렇게 라벨을 선택하는 칸을 볼 수 있다. 라벨은 GitHub가 이해하는 메타데이터이기 때문에 이슈 필터링이 쉬워진다. 

 

 

 

 

이슈 라벨은 레포지토리의 Issue 탭의 Labels 버튼을 통해 확인&수정&생성할 수 있다. 

 

 

 

 

 

 

모든 설정을 완료하고 커밋하면 .github/ISSUE_TEMPLATE 폴더가 생성되고 하위에 템플릿 파일들이 생성된 것을 확인할 수 있다. 


📍PR 템플릿 설정하기

PR 템플릿은 .github 폴더 하위에 PULL_REQUEST_TEMPLATE.md를 생성해서 작성해주면 된다. 

 

 

이때 PR 내에 Closes #이슈번호 를 명시해주면 편하다. 

 

1️⃣ Closes #번호란?

이 PR이 머지되면, 해당 Issue를 자동으로 닫아라

 

  • PR이 merge 되는 순간
  • 지정한 Issue가 자동으로 close

 

다음과 같은 상황에 사용하면 좋다. 

 

  • Issue의 작업이 이 PR 하나로 끝날 때
  • Feature / Bug / Enhancement 대부분 여기에 해당

 

 

이외에 Related to #이슈번호 도 명시해줄 수 있다.

2️⃣ Related to #번호란?

이 PR이 해당 Issue와 관련은 있지만, 끝내지는 않는다

 

  • Issue와 PR을 연결만 해줌
  • PR 머지돼도 Issue는 닫히지 않음

 

다음과 같은 상황에 사용하면 좋다. 

  • Issue가 여러 PR로 나뉘어 작업될 때
  • 부분 작업 / 실험 / 리팩토링 PR일 때
  • 아직 최종 해결이 아닌 경우