Git 워크플로우 따르기
핵심 규칙
production은 유일한 장기 브랜치입니다. 직접 작업하지 마십시오.
Git 쓰기 작업 전 항상:
git status --short --branch를 실행합니다.- 예상치 못한 파일이나 변경 사항이 없는지 확인합니다.
- 원격 저장소를 가져옵니다.
- 단기 작업 브랜치를 생성하거나 전환합니다.
- 브랜치를 하나의 목표로 제한합니다.
브랜치 이름
다음을 사용하십시오:
feat/<범위>fix/<범위>hotfix/<범위>test/<범위>docs/<범위>refactor/<범위>chore/<범위>
소문자 케밥-케이스를 사용하십시오. main, dev-production, changes,
update 또는 이와 유사한 모호한 이름은 절대 사용하지 마십시오.
커밋 전
git diff및git diff --staged를 검토합니다.- 관련 없는 파일을 제거합니다.
- 비밀, 개인 증거, 내부 URL, 원시 AI 세션, 고객 데이터 또는 학생 데이터가 나타나면 중지합니다.
- 변경된 범위와 관련된 검사를 실행합니다.
- Conventional Commit 메시지를 사용합니다.
- 명시적으로 요청하지 않는 한 AI 공동 작성자 트레일러를 추가하지 마십시오.
푸시 및 풀 리퀘스트
production에 직접 푸시하지 마십시오.production을 강제 푸시하지 마십시오.- 후크나 필수 검사를 우회하지 마십시오.
- 일반
--force를 사용하지 마십시오. - 명시적 승인 후에만 작업 브랜치에서
--force-with-lease를 사용하십시오. - 모든 프로덕션 변경은 풀 리퀘스트를 통해 이루어집니다.
.github/pull_request_template.md를 따르십시오.
병합 경계
Claude는 Randi가 현재 대화에서 특정 풀 리퀘스트 병합을 명시적으로 승인하지 않는 한 병합 전에 중단되어야 합니다.
스쿼시 병합만 사용하십시오. 병합 후 작업 브랜치를 삭제하십시오.
완료 보고서
보고:
- 브랜치
- 커밋
- 실행된 검사 및 결과
- 풀 리퀘스트 상태
- 기밀 검토
- 남은 위험
- 병합 승인이 여전히 필요한지 여부
전체 정책
다음을 읽고 따르십시오:
docs/governance/git-workflow.mddocs/governance/github-configuration.md