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
---
### 요청 내용
<!-- 어떤 기능이 필요한지 설명해주세요. -->
### 필요성
<!-- 왜 이 기능이 필요한가요? -->
### 구현 제안
<!-- 어떻게 구현하면 좋을지 제안해주세요. -->
### 참고 자료
<!-- 관련 문서나 예시가 있다면 링크해주세요. -->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로 건너뛸 수는 있는데, 그러면 릴리스 노트에서 그 커밋이 빠지니까 웬만하면 메시지를 고쳐서 다시 커밋한다.