-
Notifications
You must be signed in to change notification settings - Fork 3
Ground Rule
JaewonLee edited this page Jul 9, 2024
·
54 revisions
우리 팀은 효율적인 협업을 위해 다음 도구들을 활용합니다
- GitHub Discussions
- 프로젝트 관련 토론 및 아이디어 공유
- 주간 회의 안건 및 결과 정리 (일일 회의)
- 기술적 의사결정 기록 (멘토링 일지)
- GitHub Projects
- 스프린트 계획 및 작업 항목 관리
- 각 작업의 진행 상황 추적
- 마일스톤 및 릴리스 계획 수립
- Discord
- 실시간 커뮤니케이션 및 빠른 의사결정
- 기술 지원 및 문제 해결을 위한 채널 운영
- Wiki
- 개발 환경 문서화
- 도입 기술 문서화
- 커밋 메시지 작성 시 주의사항
- 제목은 50자 이내로 제한
- 제목의 형식:
\<type>(\<scope>) \<title>
type과scope는 반드시 영문 소문자로 작성title은(는) 첫 글자만 대문자(영문 기준)로 시작- 제목 끝에 마침표 생략
- 제목 작성 규칙:
- 영문: 동사 원형으로 시작하는 명령문으로 작성 (예: "Add feature", "Fix bug")
- 한글: 명사형으로 끝나도록 작성 (예: "기능 추가", "버그 수정")
- 본문은 한글 또는 영문으로 작성 가능하며, 20자마다 줄바꿈 (적절 길이를 유지해 주세요!)
- 본문은 "어떻게"보다 "무엇을", "왜"에 초점을 맞춰 작성
- 이슈 참조는 다음 키워드를 사용하여 작성:
- 관련 이슈 언급 시:
Related to #issue- 이슈 해결 시:
Closes #issue또는Fixes #issue- 여러 이슈 참조 시 쉼표로 구분 (예:
Closes #42, #45)
- 본문과 이슈 참조 사이에는 빈 줄을 삽입하여 구분
- 커밋 메시지 구조
<type>(<scope>): <title>
<body>
<footer>
- 예시(영문)
feat(user) Implement createUser method
- Add createUser method in UserService
- Implement input validation for user data
- Create unit tests for createUser method
Related to #23
- 예시(한글)
feat(user) CreateUser 메소드 구현
- UserService에 createUser 메소드 추가
- 사용자 데이터에 대한 입력 유효성 검사 구현
- createUser 메소드에 대한 단위 테스트 작성
Related to #23
- 예시(한글-영문 혼합)
feat(user) UpdateUser 메소드 성능 최적화
- Implement caching for frequently accessed user data
- 데이터베이스 쿼리 최적화로 응답 시간 50% 단축
- Add logging for tracking update operations
Closes #42, #45
| Type | 설명 |
|---|---|
| feat | 새로운 기능 추가 |
| bug | 버그 수정 |
| docs | 문서 수정 |
| style | 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 |
| refactor | 코드 리팩토링 |
| test | 테스트 코드, 리팩토링 테스트 코드 추가 |
| chore | 빌드 업무 수정, 패키지 매니저 수정 |
| question | 추가 정보 요청 |
| wontfix | 수정 하지 않은 이슈 (문제가 아니거나 당장 수정 불가) |
- 각 커밋 타입의 의미
-
feat: 새로운 기능 개발 관련 커밋 -
bug: 버그 수정 관련 커밋 -
docs: 문서 작성 및 수정 관련 커밋 -
style: 코드 스타일 혹은 포맷 등에 관한 커밋 -
refactor: 코드 리팩토링에 대한 커밋 -
test: 테스트 코드 수정에 대한 커밋 -
chore: 그 외 자잘한 수정에 대한 커밋 (빌드 스크립트 수정 등) -
question: 프로젝트에 대한 질문 혹은 추가 정보 요청 -
wontfix: 수정하지 않기로 결정한 이슈에 대한 커밋
GitHub Flow는 간단하고 효과적인 브랜칭 전략으로, 지속적인 배포를 지원합니다. 이 전략의 핵심은 main 브랜치와 기능별 브랜치의 사용입니다.
-
main 브랜치
- 항상 안정적이고 배포 가능한 상태를 유지합니다.
- 모든 변경사항은 이 브랜치에 병합됩니다.
-
기능 브랜치
- 새로운 기능 개발이나 버그 수정을 위해 생성합니다.
- main 브랜치에서 분기하여 생성합니다.
- 명명 규칙:
작업유형/기능명 - 예:
feature/payment-gateway,fix/login-error
- 새 기능 개발 또는 버그 수정 시:
- main 브랜치에서 새 브랜치를 생성합니다.
- 사용 중인 작업유형(ex. feature) 재활용
-
style,refactor,test,chore,question,wontfix와 같은 커밋 타입은 feature 브랜치에서 작업을 수행합니다.
-
- 리뷰어 지정:
- 최소 3명의 리뷰어를 지정합니다.
- 가능하다면 해당 기능 또는 영역에 익숙한 팀원을 포함시킵니다.
- 피드백 제공 및 수용:
- 리뷰어는 건설적이고 구체적인 피드백을 제공합니다.
- PR 작성자는 모든 피드백에 대해 응답하고, 필요한 경우 수정합니다.
- 승인 및 병합:
- 최소 3명의 승인이 있어야 병합이 가능합니다.
- 모든 CI/CD 검사를 통과해야 합니다.
## 개요
<!---- 변경 사항 및 관련 이슈에 대해 간단하게 작성해주세요. 어떻게보다 무엇을 왜 수정했는지 설명해주세요. -->
## 관련 이슈
<!---- 아래와 같이 Issue Number 연결 꼭 해주세요! ---->
<!---- Resolves: #(Issue Number) -->
## PR 유형
어떤 변경 사항이 있나요?
- [ ] 새로운 기능 추가
- [ ] 버그 수정
- [ ] CSS 등 사용자 UI 디자인 변경
- [ ] 코드에 영향을 주지 않는 변경사항(오타 수정, 탭 사이즈 변경, 변수명 변경)
- [ ] 코드 리팩토링
- [ ] 주석 추가 및 수정
- [ ] 문서 수정
- [ ] 테스트 추가, 테스트 리팩토링
- [ ] 빌드 부분 혹은 패키지 매니저 수정
- [ ] 파일 혹은 폴더명 수정
- [ ] 파일 혹은 폴더 삭제
- [ ] 코드 중간 통합
## PR Checklist
PR이 다음 요구 사항을 충족하는지 확인하세요.
- [ ] 커밋 메시지 컨벤션에 맞게 작성했습니다. Commit message convention 참고 (Ctrl + 클릭하세요.)
- [ ] 변경 사항에 대한 테스트를 했습니다.(버그 수정/기능에 대한 테스트).
- 🤝 Collaboration
- 💬 Git Commit Convention
- 🌿 Branching Strategy
- 🔀 Pull Request (PR) Guidelines
- 🐋 Docker
- 🎡 Kubernetes
- 🔎 Metrics
- 💊 USE/RED
- 📝 Metrics Design
- 🔥 Prometheus
- 🦖 Grafana
- ⚒️ 실제 구현