Git Rule #2
Description
User Story
프로젝트를 진행하면서 사용할 Git의 관한 몇 가지 규칙을 정의하고 따른다.
Commit Message
[#issue번호] type : 제목
- 작업 내용
resolves #issue번호
※ issue가 마무리되면 [#issue번호]와 resolves #issue번호 부분을 기입합니다.
ex-frontend>
[#31] feat : 이용자 순위 애니메이션
- 유저 프로필 hovering하면 프로필 사진 확대
- 1~3위 유저 이름은 빨간색 -> 파란색
- 1위 유저 클릭시 폭죽 효과
resolves #31
ex-backend>
[#31] feat : 주변 공원 추천 API
- ResponseDto, RequestDto 추가
- 각 Repository 인터페이스 타입 오류 수정
- Service 추가
- Controller 추가
- park 컬럼 name -> juso 수정
- API 테스트 후 오류 수정
resolves #31
Type
- feat : 새로운 기능 추가
- fix : 버그나 코드 수정
- docs : 문서 수정 (ex> README.md)
- style : 코드 포맷팅 변경 (ex> 오타 및 세미콜론 누락등)
- refactor : 코드 리팩토링
- chore : 빌드 업무 수정, 패키지 매니저 수정 등 설정 변경 (.gitignore 포함)
- merge : 작업물 merge하는 경우
브랜치 네이밍
Backend/feature-23
Labels
- Feature : 새로운 기능 구현
- Bug : 버그, 오류 수정
- Docs : 문서 수정 (README.md, Issue Template, 라이센스 등)
- Setting : 프로젝트 설정
- User Story : 설계 목표 및 규칙
AC
- Git 브랜치 전략으로 Git Flow를 사용한다. 이해가 안될 경우, 팀노션 참고
- 브랜치 네이밍 규칙을 따른다.
- Issue Template을 이용한다.
- Issue는 최대한 기능별로 나눠 작업한다. e.g) 자동차 전진기능
- Issue와 Commit 제목은 한글, 명사로 작성한다.
- Commit은 Issue를 이루는 최소한의 단위로 작업한다. e.g) 바퀴 동작, 엔진 가동
- Commit Message 규칙을 따른다.
- 작업현황을 Git Projects에서 공유한다.
- 각자 이 Repository를 fork 해서 진행한 부분을 pr한다.
- pr시 merge 옵션은 squash로 한다.
- 배포시점에 버그 발생시!!! 팀원들에게 상황을 전파하고, 해결될 때까지 FrontEnd/BackEnd 브런치에 병합하지 않습니다. 해결되면 동기화하고, 병합하시면 됩니다.
Reference
Check List
- issue 제목은 간결하고 명확한가?
- issue 내용은 모르는 사람도 파악할 수 있을 정도로 기술되었는가? (누가, 무엇을, 어떻게...)
- reference가 있다면 추가했는가?
- 유의미한 Label을 추가했는가?
- Assginees를 추가했는가?