Commit, Pull Request Convention
[type] Subject // 제목
body (option) // 본문
footer [#issueNumber] // 꼬리말
-
type: 어떤 의도로 커밋하였는가 -
subject: 제목, 코드 변경사항에 대한 짧은 요약 -
body: 긴 설명이 필요한 경우 사용. 무엇을 왜 했는지 작성 -
footer: Issue tracker ID 명시 시 사용
-
feat: 새로운 기능을 추가하는 경우 -
fix: 버그를 고친경우 -
docs: 문서를 수정한 경우 -
style: 코드 포맷 변경, 세미콜론 누락, 코드 수정이 없는경우 -
refactor: 코드 리펙토링 -
test: 테스트 코드. 리펙토링 테스트 코드를 추가했을 때 -
chore: 빌드 업무 수정, 패키지 매니저 수정 -
design: CSS 등 사용자가 UI 디자인을 변경했을 때 -
rename: 파일명(or 폴더명) 을 수정한 경우 -
remove: 코드(파일) 의 삭제가 있을 때. "Clean", "Eliminate" 를 사용하기도 함
예시 : [feat] userList의 (어떤)기능 추가
무엇을 변경했는지 또는 왜 변경했는지 설명하기
유형:#이슈 번호 형식으로 작성한다.
-
Fixes: 이슈 수정중 (아직 해결되지 않은 경우) -
Resolves: 이슈를 해결했을 때 사용 -
Ref: 참고할 이슈가 있을 때 사용 -
Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
feat : login 기능 추가
로그인 API 개발
Resolves : #111 // issue 111을 해결
Ref : #456 // issue 456를 참고해야 함
Related to: #11, #45 // issue 11, 45가 해결되지 않음
임시 프로젝트이기 때문에 간단하게 작성하기
## Summary
## Describe your changes
## Issue number and link
1인 프로젝트이기도 하고 따로 복잡하게 관리할 필요성은 없다고 생각하기 때문에 간단한 방식으로 진행한다.
- 하나의 기능을 구현할 때마다 하나의 branch를 만든다. 이 외에도 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성한다.
- 새로운 브랜치는 항상 main 브랜치에서 만든다.
- Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않는다.
- 그렇지만, 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자
- 원격 브랜치로 수시로 push한다.
- branch에 주어진 기능을 전부 구현한 뒤, 이상이 없다고 판단되면 main에 merge한다. (pull request 작성)
[tag]/[#issueNumber]/[구현할 내용]
- VO 객체는 'VO'를 제외하고 이름을 짓는다
예시 : UserVO user = new UserVO();