2022. 11. 30. 18:53ㆍGit
문서를 읽을 때, 우리가 가독성을 높이려면 어떤 format이 있는 것이 편리합니다. 논문 같은 것들보면 (물론 내용이 어려워서 이해는 어려울 수 있습니다.) 구조화 된 포맷에서 내용을 작성합니다. 그래서 핵심이 뭔지, 그 핵심을 검증하는 논지가 뭔지를 구조적으로 파악이 가능합니다. 이런 부분은 코드를 작성하는데도 반영이 됩니다. 그리고 git에 수정 내용을 commit 할 때도 이런 format이 있다면 효율적으로 변경 사항이 파악이 가능합니다.
NextStep의 TDD 과정을 들으면서 'Commit Message Conventions'에 대해서 알게 되었습니다.
Commit message의 기본 구조
구조는 아래와 같습니다.
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>보통 이렇게 쓴다고 합니다. 가운데 BLAND LINE을 추가하는 것은 가독성을 높이기 위함으로 보입니다.
type에 포함 될 수 있는 내용은 아래와 같습니다. ( 출처 )
- feat : 새로운 기능 추가, 기존의 기능을 요구 사항에 맞추어 수정
- fix : 기능에 대한 버그 수정
- build : 빌드 관련 수정
- chore : 패키지 매니저 수정, 그 외 기타 수정 ex) .gitignore
- ci : CI 관련 설정 수정
- docs : 문서(주석) 수정
- style : 코드 스타일, 포맷팅에 대한 수정
- refactor : 기능의 변화가 아닌 코드 리팩터링 ex) 변수 이름 변경
- test : 테스트 코드 추가/수정
- release : 버전 릴리즈
scope : 어디가 변경되었는지 구체적으로 작성해줍니다. 무슨무슨 파일. 무슨무슨 메서드 등등 저는 개인적으로 구체적으로 나열하는 것이 중요하다고 생각합니다.
subject : 해당 커밋의 제목입니다. 해당 commit이 무엇을 하는것인지 명확하게 기술하면 좋습니다. Commit의 단위를 작게 잡아서 body를 포함할 수 있는 경우라면 body를 생략할 수 있습니다.
body : subject와 type으로 표현이 가능하다면 생략도 가능합니다. 작성이 필요하다면 before -> after 형태로 작성하면 좋을 것 같습니다.
footer : 어떠한 이슈에 대한 commit인지 issue number를 포함합니다. 좋은 예시로 이슈번호를 포함한다고 합니다. #1 이렇게 포함하거나 close #1 처럼 작성 할수 있다고 합니다.
마치며
정말 Git과 같은 형상 관리툴을 잘 쓰는 조직에서 일하는 것도 복인가 싶습니다. 앞으로는 개인 프로젝트에서도 위 규칙을 잘 지키면서 작업을 해야겠다는 생각이 듭니다.