스프링을 활용하는 백엔드 스터디 프로젝트123567
type: subject
(공백)
body
타입은 아래 리스트 중 하나만을 선택.
- feat : 새로운 기능 추가
- fix : 버그 수정
- docs : README 문서 수정 혹은 추가적인 문서가 추가 변경될경우
- style : 주석, 디버깅 추가·수정·삭제, 오타수정 등 메인 로직의 변화는 없음
- refactor : 로직의 결과값은 동일하지만 코드의 변경을 통해 개선됐을경우
- test : 테스트 코드 추가 혹은 테스트 코드 리팩토링. 메인 로직 코드 변경은 없음
- chore : (단어 뜻 : 하기싫은 일) 기존에 존재하던 폴더 명, 파일 명 변경 혹은 경로 변경. 또는 설정파일 변경 등 메인 로직 코드 변경은 없음
주제는 50자를 넘어서는 안된다. 커밋이 수행 한 작업에 대해 명령형으로 작성한다.
모든 커밋들이 바디를 적어야 할 정도로 복잡하진 않기 때문에 바디는 옵션이고, 커밋이 약간의 설명과 문단이 필요할 때 바디가 사용된다. '어떻게'가 아닌 '무엇을' 그리고 '왜'에 대한 설명을 위해 바디를 사용해야한다.
바디를 적을 때, 타이틀과 바디 사이에 공백을 적어야 하고 각 줄에 글자가 72자를 넘지 않도록 해야한다.
fix: CardList 컴포넌트 클릭 시 공백으로 나오는 오류 수정
모바일 버전에서 CardList의 img 부분 클릭 시 공백으로 나오는 오류 수정.
PC버전은 이상없음.
커밋은 그래서 언제 해야할까? 자주 해야 좋은걸까? 30분에 한 번씩? 의미가 있을 때? 커밋의 횟수에 대해서는 정해진 컨벤션은 없었다. 대신 커밋을 얼마나 자주 해야하는 질문들에 up-vote를 많이 받은 답변들을 모아봤다.
- 어떤 기능에 대한 테스트가 끝났을 때. 보통 한 시간에 두 번 정도. 다섯번은 너무 많다.
- 기능에 기반해서 커밋을 해야지 시간을 정해서 커밋을 하면 안된다. 새로운 기능을 추가했을 때 기능이 커밋할 만 하거나, 작동하는 메소드를 추가했거나, 글씨를 수정했거나, 잘못된 파일 들여쓰기를 수정했거나 등등일때 커밋해야한다. 커밋이 의미가 있다면 작은 것을 커밋하는 것은 전혀 잘못된점이 아니다. 의미 없는 너무 잦은 커밋은 히스토리로 이슈를 추적하는데 있어서 읽기 어렵게 한다.
- 새로운 테스트 케이스를 추가할 때, 테스트가 통과됐을 때, 변수 이름을 변경했을 때, 메소드를 삭제했을 때, 상태를 변경했을 때 등... 사실 커밋한 대상의 중요성은 중요하지 않다