← 글 목록

notes

(github). - message

GitHub 메시지·커밋과 협업 기록을 관리하는 기본 사용 메모.

  • PR 템플릿은 .github/pull_request_template.md에 두면 PR을 열 때 본문에 자동으로 채워진다.
  • 커밋 메시지는 feat:, fix: 같은 타입을 앞에 붙이는 컨벤션을 쓴다.
  • commitlint와 husky의 commit-msg 훅으로 규칙에 안 맞는 커밋은 막는다.

팀 레포를 새로 팔 때마다 PR 설명이 "수정했습니다" 한 줄로 올라오는 게 싫어서, 템플릿을 아예 레포에 박아 두기로 했다. 쓰는 사람은 빈칸만 채우면 되고 리뷰하는 쪽도 뭘 봐야 할지 바로 보인다.

템플릿이 끼어드는 곳은 세 군데다. 이슈 만들 때, 커밋할 때, PR 열 때. 아래는 그 순서대로 정리한 것.

파일 위치

GitHub은 정해진 경로에 있는 파일만 템플릿으로 읽는다. 처음에 PR_TEMPLATE.md로 만들었다가 아무것도 안 떠서 한참 헤맸다.

기본 브랜치(main)에 머지돼 있어야 동작한다. 작업 브랜치에만 올려 두면 안 뜬다.

PR 템플릿

체크리스트를 길게 만들면 결국 아무도 안 읽어서 유형, 변경 사항, 관련 이슈, 스크린샷 정도만 남겼다.

제일 쓸모 있는 건 closes #번호 한 줄이다. PR이 기본 브랜치로 머지될 때 그 이슈가 같이 닫힌다. fixes, resolves도 똑같이 먹는다. 이슈 정리를 따로 안 해도 돼서 이건 꼭 남겨 둔다.

pull_request_template.md 전체
## PR 유형
- [ ] 기능 추가
- [ ] 버그 수정
- [ ] 리팩토링
- [ ] 문서 수정
- [ ] 스타일 변경
- [ ] 테스트 추가
- [ ] CI/CD 변경

## PR 내용
<!-- 변경사항 및 관련 이슈에 대해 설명해주세요. -->

### 변경 사항
- 

### 관련 이슈
- closes #이슈번호

## 스크린샷
<!-- UI 변경사항이 있다면 스크린샷을 첨부해주세요. -->

## 체크리스트
- [ ] 테스트 코드를 작성했나요?
- [ ] 문서를 업데이트했나요?
- [ ] 브랜치 규칙을 준수했나요?
- [ ] self-review를 진행했나요?

## 참고 사항
<!-- 리뷰어가 알아야 할 내용이 있다면 적어주세요. -->

<!-- --> 주석은 PR 화면에서 안 보이니까 작성 가이드는 주석으로 넣어 두면 깔끔하다.

Issue 템플릿

예전엔 버그 리포트랑 기능 요청을 파일 하나에 같이 넣어 뒀는데, 그러면 쓰는 사람이 절반을 지워야 해서 파일을 둘로 나눴다. 파일마다 맨 위에 front matter(name, about, labels)를 넣어 두면 New issue 화면에서 카드로 골라지고 라벨도 자동으로 붙는다.

버그는 재현 순서가 없으면 손을 못 대서 그 칸은 번호를 미리 찍어 뒀다.

bug_report.md
---
name: 버그 리포트
about: 동작이 이상할 때
labels: bug
---

### 증상
<!-- 어떤 문제가 발생했는지 명확하게 설명해주세요. -->

### 재현 방법
1. 
2. 
3. 

### 예상 동작
<!-- 원래 어떻게 동작해야 하나요? -->

### 실제 동작
<!-- 실제로 어떻게 동작하나요? -->

### 스크린샷
<!-- 가능하다면 스크린샷을 첨부해주세요. -->

### 환경 정보
- OS:
- 브라우저:
- 버전:
feature_request.md
---
name: 기능 요청
about: 이런 게 있으면 좋겠다
labels: enhancement
---

### 요청 내용
<!-- 어떤 기능이 필요한지 설명해주세요. -->

### 필요성
<!-- 왜 이 기능이 필요한가요? -->

### 구현 제안
<!-- 어떻게 구현하면 좋을지 제안해주세요. -->

### 참고 자료
<!-- 관련 문서나 예시가 있다면 링크해주세요. -->
ISSUE_TEMPLATE/config.yml
blank_issues_enabled: false

커밋 메시지 컨벤션

커밋 메시지는 Conventional Commits 형식을 쓴다. 처음엔 다들 지키다가 급해지면 수정, ㅇㅇ 같은 게 섞이기 시작해서, husky + commitlint로 커밋 단계에서 막아 버렸다. 나중에 semantic-release로 버전이랑 CHANGELOG를 자동으로 뽑을 때도 이 형식이 그대로 쓰인다.

꼬리말에 BREAKING CHANGE:가 들어가거나 feat!:처럼 느낌표를 붙이면 major가 올라간다.

husky + commitlint 붙이기

pnpm add -D husky @commitlint/cli @commitlint/config-conventional
npx husky init
echo 'npx --no -- commitlint --edit "$1"' > .husky/commit-msg
// commitlint.config.js
export default {
  extends: ['@commitlint/config-conventional'],
};

husky init이 package.json에 prepare 스크립트를 넣어 줘서, 팀원이 pnpm install만 하면 훅이 같이 깔린다. 형식이 틀리면 커밋 자체가 안 된다.

$ git commit -m "로그인 수정"
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

급할 때 --no-verify로 건너뛸 수는 있는데, 그러면 릴리스 노트에서 그 커밋이 빠지니까 웬만하면 메시지를 고쳐서 다시 커밋한다.