NotionNext 문서

Appearance

커밋과 PR 협업 규칙 ​

English

1. 브랜치 전략 ​

  • 항상 최신 main에서 새 브랜치를 만듭니다.
  • 하나의 브랜치에는 한 종류의 변경만 담습니다(하나의 테마/하나의 기능/하나의 수정).
  • 권장 브랜치 이름:
    • fix/...
    • feat/...
    • chore/...
    • docs/...

2. 제출 전 검사 ​

bash
yarn lint
yarn type-check
yarn test

변경이 빌드 흐름에 영향을 준다면 다음도 추가 실행하는 것을 권장합니다.

bash
yarn build

3. 커밋 규칙 ​

Conventional Commits를 권장합니다.

  • feat(scope): ...
  • fix(scope): ...
  • docs(scope): ...
  • chore(scope): ...

4. PR 내용 권장 템플릿 ​

  • 배경/문제
  • 방안 설명(왜 이렇게 했는지)
  • 변경 범위(파일 목록)
  • 위험과 호환성 평가
  • 검증 단계(로컬 명령 + 결과)

5. 명확한 금지 사항(충돌 줄이기) ​

  • 개인 .env.local을 저장소에 커밋하지 않습니다.
  • 작업과 무관한 개인화된 config.js 변경을 커밋하지 않습니다.
  • 서로 무관한 여러 기능을 하나의 PR에 넣지 않습니다.
  • 메인 브랜치에 개발 변경을 직접 커밋하지 않습니다.

6. 리뷰어에게 도움이 되는 방식 ​

  • 가능한 한 “최소 패치”로 만듭니다.
  • 큰 변경은 여러 작은 PR로 나눕니다.
  • PR 설명에 “호환성을 깨는 변경 포함 여부”를 명시합니다.

7. 사용자 문서(user-guide) ​

docs/user-guide/를 수정하거나 추가할 때는 문서 유지보수 워크플로를 따르세요. README.md, ARTICLE_INDEX.md를 함께 갱신하고, conf/*.config.js의 설정 키와 일치하도록 유지합니다.