GitHub Issues → PR 워크플로우
전체 흐름
이슈 생성 (draft 라벨)
↓
draft 라벨 제거 (작업 가능 상태)
↓
작업할 이슈 선택 → wip 라벨 추가
↓
브랜치 생성 (issue/<번호>-<slug>)
↓
구현
↓
PR 생성 (Closes #<번호>)
↓
머지 → 이슈 자동 close
1. 이슈 생성
이슈를 만들 때는 항상 --label draft를 붙인다. 아직 준비가 안 된 상태라는 표시다.
gh issue create \
--title "포스트: Justfile 소개 글 작성" \
--body "Justfile이 무엇인지 요약하는 블로그 포스트를 작성한다." \
--label draft
draft 라벨은 사람이 직접 제거한다. 제거되면 작업 가능 상태가 된다.
2. 작업 가능한 이슈 찾기
draft도 wip도 없는 open 이슈가 작업 대상이다.
gh issue list --search "-label:draft -label:wip"
3. 작업 시작
이슈를 골랐으면 wip 라벨을 붙이고 브랜치를 만든다.
# wip 라벨 추가
gh issue edit 18 --add-label wip
# main 최신화 후 브랜치 생성
git pull
git checkout -b issue/18-add-justfile-post
브랜치명은 issue/<번호>-<slug> 형식을 따른다.
4. 라벨 상태 정리
| 라벨 | 의미 |
|---|---|
draft |
생성됐지만 아직 준비 안 됨 (사람이 직접 제거) |
| (없음) | 작업 가능 상태 |
wip |
현재 작업 중 |
5. PR 생성
구현이 끝나면 원격에 푸시하고 PR을 만든다.
git push -u origin issue/18-add-justfile-post
gh pr create \
--title "포스트: Justfile 소개 글 작성" \
--body "Justfile이 무엇인지 요약하는 블로그 포스트를 추가합니다.
Closes #18"
body에 Closes #<번호>를 넣으면 PR이 머지될 때 이슈가 자동으로 close된다.
왜 이렇게 하나?
draft라벨로 아직 논의 중인 이슈와 실행 가능한 이슈를 분리할 수 있다.wip라벨로 누가 어떤 이슈를 진행 중인지 한눈에 파악된다.- main 직접 push를 막고 PR을 통해서만 머지하면, 코드 리뷰 기회가 생기고 실수를 줄일 수 있다.
Closes #<번호>연결로 PR과 이슈 추적이 자동화된다.