협업 규칙

4. 응용 변형 예제

4.1 release 브랜치와 태그로 배포 마무리

git-flow 팀은 develop 에서 release/1.2 를 딴 뒤 버그 수정만 반영해 안정화합니다. 안정화가 끝나면 main 에 병합하고 v1.2.0 태그를 찍은 다음 develop 에도 다시 병합해 수정 내용을 되돌려 보냅니다.

4.2 이슈 번호와 BREAKING CHANGE 실전 커밋 메시지

feat(auth): OAuth2 로그인 방식으로 교체

기존 자체 로그인 API 를 OAuth2 로 바꿨습니다.
기존 클라이언트는 새 토큰 형식을 지원해야 합니다.

BREAKING CHANGE: /api/login 응답 형식이 바뀝니다.
Closes #58

제목의 feat(auth) 로 범위를 밝히고, 본문 마지막에 BREAKING CHANGE 와 이슈 번호를 각각 한 줄로 둡니다.

4.3 pre-commit 훅에 비밀키 패턴 검사 추가

if git diff --cached | grep -qE 'AWS_SECRET_ACCESS_KEY|BEGIN (RSA|EC) PRIVATE KEY'; then
  echo "pre-commit: 비밀키로 보이는 내용이 포함됐습니다" >&2
  bad=1
fi

예제 3 의 pre-commit 훅 뒤에 이 검사를 추가하면 AWS 키나 개인키 헤더가 스테이징된 변경에 섞였을 때 커밋 전에 막습니다.

4.4 코드 리뷰 전 자기 점검 목록

• 커밋 메시지가 Conventional Commits 형식을 따르는가.
• 관련 없는 파일 변경(포맷터가 건드린 파일 등)이 섞이지 않았는가.
• 테스트를 돌려 통과를 확인했는가.
• PR 설명에 "무엇을 왜" 바꿨는지 적었는가.

4.5 작은 PR 로 쪼개는 습관

한 PR 은 한 가지 목적만 담습니다. 변경 줄 수가 많아지면 리뷰어가 대충 훑고 승인하기 쉬워 버그를 놓칩니다. 기능이 크면 브랜치를 여러 개로 나누고 순서대로 PR 을 올립니다.