📁 TIKI_SERVER
├── .github
├── .gradle
├── .idea
├── build
├── gradle
├── src.main
│ ├──java.com.tiki.server
│ ├── auth
│ ├── common
│ ├── document
│ ├── member
│ ├── controller
│ ├── dto
│ ├── entity
│ ├── message
│ ├── repository
│ ├── service
│ ├── memberteammanager
│ ├── team
│ ├── timeblock
서버 들의 Git Commit Message Rules
- 반영사항을 바로 확인할 수 있도록 작은 기능 하나라도 구현되면 커밋을 권장합니다.
- 기능 구현이 완벽하지 않을 땐, 각자 브랜치에 커밋을 해주세요.
[태그] 제목의 형태
| 태그 이름 | 설명 |
|---|---|
| FEAT | 새로운 기능을 추가할 경우 |
| FIX | 버그를 고친 경우 |
| CHORE | 짜잘한 수정 |
| DOCS | 문서 수정 |
| INIT | 초기 설정 |
| TEST | 테스트 코드, 리펙토링 테스트 코드 추가 |
| RENAME | 파일 혹은 폴더명을 수정하거나 옮기는 작업인 경우 |
| STYLE | 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 |
| REFACTOR | 코드 리팩토링 |
[태그] 설명형식으로 커밋 메시지를 작성합니다.- 태그는 영어를 쓰고 대문자로 작성합니다.
예시 >
[FEAT] 검색 api 추가
티키 들의 WorkFlow : Gitflow Workflow
-
Develop, Feature, Hotfix 브랜치
-
개발(develop): 기능들의 통합 브랜치
-
기능 단위 개발(feature): 기능 단위 브랜치
-
버그 수정 및 갑작스런 수정(hotfix): 수정 사항 발생 시 브랜치
-
개발 브랜치 아래 기능별 브랜치를 만들어 작성합니다.
- Develop에 직접적인 commit, push는 금지합니다.
- 커밋 메세지는 다른 사람들이 봐도 이해할 수 있게 써주세요.
- 작업 이전에 issue 작성 후 pullrequest 와 issue를 연동해 주세요.
- 풀리퀘스트를 통해 코드 리뷰를 전원이 코드리뷰를 진행합니다.
- 기능 개발 시 개발 브랜치에서 feature/기능 으로 브랜치를 파서 관리합니다.
- feature 자세한 기능 한 가지를 담당하며, 기능 개발이 완료되면 각자의 브랜치로 Pull Request를 보냅니다.
- 각자가 기간 동안 맡은 역할을 전부 수행하면, 각자 브랜치에서 develop브랜치로 Pull Request를 보냅니다.
develop 브랜치로의 Pull Request는 상대방의 코드리뷰 후에 merge할 수 있습니다.
- develop
- feature/issue_number-도메인-http Method-api
- fix/issue_number-도메인-http Method-api
- release/version_number
- hotfix/issue_number - Short Description
예시 >
feature/#3-user-post-api
- P1: 꼭 반영해주세요 (Request changes)
- P2: 적극적으로 고려해주세요 (Request changes)
- P3: 웬만하면 반영해 주세요 (Comment)
- P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
- P5: 그냥 사소한 의견입니다 (Approve)
- given, when, then을 사용한다.
- 테스트 메서드명은 다음과 같이 작성한다. -> 메서드명_테스트하고자하는상태_예상되는결과 (ex. giveCotton_CottonCountIs0_NotEnoughCotton)
- 설마 이런 거까지 생각해야하나싶은 거까지 작성한다. (ex. 솜뭉치를 여러 개 줄 수 있다.)
- 다수의 값을 다룰 때는 @ParameterizedTest를 활용한다.
| 🍀 남궁찬 | 🍀 신민규 |
|---|---|
| Server Developer | Server Developer |
| 프로젝트 세팅 |
프로젝트 세팅 |