개발자가 5명만 넘어가도 팀 내에 명확한 'Git 룰(Rule)'이 없으면 브랜치가 뒤엉키고, 누가 무슨 코드를 고쳤는지 추적할 수 없는 혼돈 상태가 됩니다. 이 문서는 팀이 구성될 때 반드시 합의하고 문서화해야 하는 4대 핵심 운영 정책을 정의합니다.
1. PR 머지 전략 3종 비교 및 팀 가이드라인
GitHub의 PR 머지 버튼에는 3가지 옵션이 있습니다. 팀 성격에 맞게 하나로 통일하는 것이 좋습니다.
| 머지 방식 | 동작 방식 | 장단점 및 추천 상황 |
|---|---|---|
| Squash and merge ⭐ 가장 추천 | 브랜치 안의 모든 커밋(자잘한 오타 수정, WIP 등)을 단 1개의 깔끔한 커밋으로 압축하여 develop에 합침 | 장점: develop 히스토리가 극도로 깨끗해짐. 추천: 대부분의 기능(feature) 브랜치 머지 시 기본값 |
| Create a merge commit (--no-ff) | 브랜치의 모든 커밋을 보존하면서 두 브랜치를 잇는 머지 커밋을 생성 | 장점: 상세한 과거 작업 흐름이 남음. 추천: release 브랜치나 hotfix를 main에 합칠 때 |
| Rebase and merge | 각각의 커밋을 머지 커밋 없이 그대로 대상 브랜치 뒤에 이어 붙임 | 단점: 커밋 단위가 이미 완벽하게 정돈되어 있지 않으면 지저분한 커밋들이 develop에 그대로 노출됨 |
2. 브랜치 보호 및 PR 승인 정책
- Direct Push 차단:
main,staging,develop브랜치는 오직 관리자라도 직푸시할 수 없도록 강제합니다. - 최소 승인(Approval) 수: 기본 1명(중요 코어 모듈은 최소 2명)의 승인을 받아야 머지가 활성화됩니다.
- Stale Reviews 무효화: 리뷰어가 승인한 뒤 작업자가 코드를 추가로 푸시하면, 이전 승인이 자동으로 취소되어 재검토를 거치도록 설정합니다.
3. 커밋 메시지 및 이슈 트래커 연동 컨벤션
커밋 메시지는 미래의 동료(그리고 6개월 뒤의 나)를 위한 편지입니다.
[ 커밋 메시지 표준 구조 ]
<타입>: <제목> (50자 이내, 개조식으로 명확하게)
<본문> (선택 사항: '어떻게'보다 '왜(Why)' 수정했는지 배경 설명)
<꼬리말> (선택 사항: 연관 이슈 티켓 번호 연결)실제 작성 예시
feat: 소셜 로그인 토큰 만료 시 자동 갱신 로직 추가
기존에는 토큰이 만료되면 401 에러와 함께 로그아웃되었으나,
사용자 경험 개선을 위해 Refresh Token을 이용한 자동 재발급 로직을 추가함.
Closes #142, Ref #984. 보안 시크릿 키 유출 방지 (Pre-commit Hook)
실수로 API 키나 비밀번호를 커밋하는 것을 막기 위해, 커밋 실행 전 자동으로 검사하는 pre-commit 훅을 도입합니다.
# husky 또는 pre-commit 도구를 통해 커밋 시 .env 유입 자동 차단
npx husky add .husky/pre-commit "npm test && git-secrets --pre_commit_hook"
