들어가기 전
Git의 커밋 단위는 기능 목록 단위로 추가합니다.
커밋 컨벤션은 커밋 메시지를 명확하고 일관성 있게 작성하여 프로젝트의 변경 사항을 쉽게
파악하고, 버전 관리를 자동화하는 데 도움을 주기 위해 만들어졌습니다.이에 AngularJS Git Commit Message Conventions 를 참고하여 커밋 형식을 알아보려 합니다.
커밋 메시지 구조
위 컨벤션의 구조는 다음과 같습니다.
커밋 메시지를 유형(Type), 범위(Scope), 제목(Subject) 으로 구조화하는 것입니다.
커밋 메시지 형식
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>유형(Type)
맨 처음에 나오는 유형(type)에는 어떤 종류의 변경 사항인지 나타냅니다.
- feat: 새로운 기능(feature) 추가
- fix: 버그수정
- docs: 문저 변경 (코드 변경 없음)
- style: 코드 스타일 변경 (포멧팅, 세미콜론(
;) 등 기능적 변경 없음)- refactor: 코드 리펙토링 (기능 변경 없이 코드 구조 개선)
- test: 테스트 코드 추가 또는 수정
- chore: 빌드 작업, 패키지 매니저 설정 등 (프로덕션 코드 변경 없음)
패키지 매니저 : 특정 플렛폼 위에 응용 소프트웨어 패키지를 설치 및 관리하는 프로그램
프로덕션 코드 : 사용자가 실제로 사용하는 서비스에 배포되는 소스 코드
범위(Scope)
유형 뒤 나오는 스코프
()안에는 변경 부분의 위치를 나타냅니다.
ex) 특정 모듈, 컴포넌트 이름
하지만 이는 선택사항입니다.
제목(subject)
제목(subject)에서는 변경 사항에 대한 간결한 설명을 작성하며 아래 규칙을 따릅니다.
- 명령, 현재 시제를 사용합니다.
- 첫 글자를 대문자로 쓰지 않습니다.
- 끝에 마침표(.)가 없습니다.
본문(body)
본문(body)은 제목과 마찬가지로 명령, 현재 시제를 사용합니다.
변화에 대한 동기를 포함하고 이전 행동과 대조합니다.
다른 사항은 Git 커밋 메시지 작성 를 참조합니다.
바닥글(footer)
바닥글(footer)에는 모든 주요 변경 사항(변경 사항 설명, 정당성 및 마이그레이션 참고사항)을 작성합니다.
참조 문제, 닫힌 버그는 다음과 같이
Close키워드를 접두사로
붙여 바닥글의 별도 줄에 나열해야 합니다.
문제가 하나 있는 경우:
Closes #234
여러 문제가 있는 경우:
Closes #123, #245, #992기능(Feature)?
커밋 메시지를 작성하기 전 기능의 경계를 알아봅시다.
기능은 단순히 메서드 하나를 구현하는 것이 아닌
사용자 또는 시스템 관점에서 의미 있는 가치를 제공하는 작업의 단위라고 생각하는 것이 좋습니다.
사용자가 직접 경험할 수 있는 변화이거나 시스템의 동작에 중요한 영향을 미치는
변경사항을 말합니다.
예를 들어?
- User Story(사용자 스토리)의 구현일 때
"사용자가 (무엇을) 할 수 있다"와 같은 사용자 중심의 코드를 구현하는 것
ex) 사용자는 게시글에 좋아요를 누를 수 있다면?
커밋 메시지는feat: 게시글 좋아요 기능 추가이렇게 작성될 수 있습니다.
- 새로운 API 엔드포인트를 개발했을 때
특정 사용자의 모든 게시글 목록을 반환하는
/users/{userId}/postsAPI를 개발했다면?
커밋 메시지는feat(users): 특정 사용자 게시글 목록 조회 API 추가
그럼 기능으로 보기 어려운 것들을 예로 들어봅시다.
- 단순 헬퍼(Helper) 메서드 구현 및 도입 시
문자열의 앞뒤 공백을 제거하는 유틸리티 메서드 추가를 했을 때
이 경우에는 더 큰 기능의 일부로 묶거나 여러 곳에서 사용될 범용적인 로직이라면
refactor나chore가 더 적합합니다.
- 변수명 또는 코드 구조 개선
user_id라는 변수명을userId로 변경했을 때
이 경우는refactor또는style에 해당합니다.
🤔 만약 커밋을 잘게 쪼개고 싶다면?
문뜩 이런 생각이 든다. 커밋을 잘게 쪼개고 싶은데
"기능 구현이 완료되지 않은 코드에 대한 커밋 메시지를 어떻게 작성해야할까?"
제 경우에는 하나의 기능(API)이나 하나의 테스트를 구현하면 커밋을 가져갔는데 이렇게 되었을 때
오류가 터졌다면 그것을 찾기위한 여정이 오래걸렸던 경험이 많습니다.그렇기에 최근에는 커밋을 작게 가지는 것에 관심이 갔는데
또 이렇게 되면 하나의 기능 아래 너무 많은 커밋이 작성됩니다.그래서 여기에는 정답이 있지 않지만 커뮤니티를 보고 저만의 명확한 기준점을 잡아보려고합니다.
- 이전 커밋과 유의미한 차이가 있어 하나의 작업이라고 생각되면 따로 커밋
- 테스트를 통해 정상 동작한다면 커밋
- 별도의 기능 중 오류 발생 시 먼저 수정 진행 후 커밋
많이 작성해보고 본인만의 스타일을 찾아가는 게 좋다고 생각합니다.
또 너무 컨벤션이나 원칙에 집착하기 보단
먼저 기능 구현과 요구사항 충족에 집중하고 지키는 것이 좋다고 생각합니다.
마무리하며
마지막으로 커밋 메시지를 작성하기 전에 스스로에게 질문을 던져야 합니다.
"무엇이 달라졌는가?"
- "사용자에게 새로운 가치가 생겼나?" ->
feat- "기존의 문제가 해결되었나" ->
"fix"- "코드가 더 깔끔하고 효율적으로 바뀌었나?" ->
"refactor"
