그거 아세요? 우리가 쓰는 커밋 컨벤션, Angular에서 왔어요.

그거 아세요?

우리가 쓰는 커밋 컨벤션, Angular에서 왔어요.

우리가 자주 쓰는 feat, fix, chore 같은 커밋 메시지 타입,
사실은 Angular 팀에서 만든 커밋 메시지 작성 규칙이에요.

2012년경 AngularJS 프로젝트에서 커밋 메시지 품질을 높이기 위해 이 컨벤션이 도입되었고, 이후 많은 오픈소스와 실무 프로젝트에서 사실상 표준처럼 사용되고 있어요.

또한 이 규칙은 semantic-release 같은 자동 버전 관리 도구와도 잘 맞아요.
예를 들어 커밋 메시지에 따라 다음과 같은 자동 릴리즈 흐름이 가능하죠:

• feat: → minor 버전 증가
• fix: → patch 버전 증가
• BREAKING CHANGE: → major 버전 증가

그런데 WIP는 없다고요?

맞아요. WIP:는 Angular 커밋 컨벤션에 공식적으로 포함되어 있진 않아요.
하지만 중간 저장이나 초안 작업 상태를 나타내기 위해 사용된다고 해요.

그래서 저는 Angular 커밋 컨벤션을 기반으로 하되, WIP (Work In Progress) 커밋 메시지를 관용적으로 추가해서 사용하고 있어요.

정리해둔 내용은 아래에서 볼 수 있으니, 팀 커밋 컨벤션 문서가 필요하다면 참고해보세요.

커밋 메시지 컨벤션

<BLANK LINE>은 각 구조를 구분짓기 위한 빈 행입니다.

1. 멀티 라인 커밋 메시지

제목 한 줄 + 본문(설명) + 푸터 형태로 작성합니다.
커밋 내용의 배경, 맥락, 해결 방식 등을 자세히 설명할 수 있습니다.

<type>([optional scope]): <subject>
<BLANK LINE>
[optional body]
<BLANK LINE>
[optional footer(s)]

• git commit 입력 후 Vim 에디터에서 i를 눌러 멀티라인 커밋 메시지 작성
• <BLANK LINE>은 각 구조를 구분짓기 위한 빈 행

2. 싱글 라인 커밋 메시지

제목만 있는 간단한 메시지로 로그 뷰어의 기본 형태입니다.
변경 내용이 단순하거나 설명이 필요 없는 경우 사용합니다.

git commit -m "<type>(<scope>): <subject> [optional footer(s)]"

커밋 메시지 구성 요소와 규칙

<type>

• feat : 새로운 기능 추가
• fix : 버그 수정, 동작하지 않는 기능 수정
• docs : 문서 작성, 수정
• style : 스타일 관련, 형식 지정, 누락된 세미콜론 등 코드 포맷팅 등 코드 변경이 없는 경우
• refactor : 동작은 하지만 더 좋은 방향으로 코드 수정
• test : 테스트 코드 수정, 추가
• chore : 빌드, 패키지 매니저 등 유지 보수
• WIP : 아직 완료되지 않은 작업의 중간 저장용 임시 커밋

<scope>

커밋 변경 위치를 지정하는 모든 것이 될 수 있습니다.
함수가 변경되었으면 함수 이름, 메소드가 추가되었으면 class 이름등 영향받는 영역을 표기합니다.

feat(auth): 소셜 로그인 기능 추가
fix(ui): 버튼 색상이 테마와 다르게 표시되던 문제 수정
refactor(api): 유저 목록 API 호출 방식 변경

<subject>

1. 최대 50자로 제한
   (중간에 잘리거나 줄바꿈 대비)
2. 영어로 작성시 첫 글자는 소문자
   (문장의 시작은 type 이기 때문, 고유명사 제외)
3. 현재 시제의 명령형으로 작성
   (“이 커밋은 무엇을 한다”고 말하듯 일관성 있게 쓰는 것)
4. 점(.) 사용 금지
   (자동 릴리즈 메시지나 changelog 생성 시 여러 줄처럼 잘못 파싱될 위험 대비)

[optional body]

1. 본문은 공백포함 최대 72자로 줄바꿈
   (한 줄이 화면을 넘어서지 않도록 가독성을 위해)
2. 영어로 작성시 첫 글자는 대문자
   (subject 와 다르게 첫 시작이기 때문에)
3. '어떻게' 바뀐지 설명하지 말고 변경 사항을 '무엇'을 '왜' 바꾸었는지 중심으로 서술
   ('어떻게 바꿨는지'는 깃헙 코드에 나와 있기 때문에 배경과 목적 위주로 작성)

[optional footer(s)]

• 연관된 이슈 번호 등을 작성
• 툴에서 자동 추적이 필요한 메타 정보
• multiple issues일 경우 쉼표(,)로 구분하여 기록 (Closes #123, #245, #992)

키워드	용도
Closes: 또는 Fixes:	특정 이슈가 마무리 되었을 때
Refs: 또는 Related-to:	관련된 이슈를 참조할 때
BREAKING CHANGE:	하위 호환이 깨지는 변경사항 표시 (semantic-release와 연동되어 major 버전 자동 증가)
Co-authored-by:	공동 커밋자 정보 기입 (여러 명이 작업한 커밋 표시)
Reviewed-by:	코드 리뷰어 명시
Signed-off-by:	서명(서약)을 명시할 때, 보통 오픈소스 컨트리뷰션 시 사용
Reverts:	특정 커밋을 되돌릴 때 사용 (Reverts commitHash)

규칙을 지킨 커밋 예시

한 줄 커밋 메시지 예시

feat: 로그인 시 remember me 기능 추가 #74
fix(api): POST 요청 헤더 누락 문제 수정

멀티라인 커밋 메시지 예시

feat(auth): 로그인 시 remember me 기능 추가

로그인 시 사용자가 '기억하기' 옵션을 선택하면 로컬 스토리지에 토큰을 저장하도록 기능을 추가합니다.
이로 인해 브라우저를 종료해도 사용자가 로그인 상태를 유지할 수 있게 됩니다.

BREAKING CHANGE: 로그인 API 응답 구조가 변경되었습니다. 토큰 외에 expires 항목이 추가되었으므로, 관련 파싱 로직을 수정해야 합니다.
Closes: #123
Related-to: #95
Co-authored-by: 홍길동 <hong@example.com>
Reverts: a3c0b9d2ee14b0b3cdbf03c6cf93a12e34a1d9b9

WIP 커밋은 언제 사용할까요?

작업을 시작했지만 아직 완성되지 않은 기능을 개발 중일 때, 중간 저장을 위해 WIP:(Work In Progress) 커밋 메시지를 사용할 수 있습니다.

git commit -m "WIP: 사용자 프로필 페이지 개발 중"

언제 쓰면 좋을까요?

• 브랜치를 전환해야 하는데, 현재 상태를 저장하고 싶을 때
• 코드가 완성되진 않았지만 작업 흐름을 끊기 싫을 때
• 팀원에게 이 기능은 아직 작업 중입니다 라고 명확하게 전달하고 싶을 때

Draft PR과 함께 쓰면 더 좋아요

GitHub에서 PR을 생성할 때 'Create draft pull request'를 선택하면, 리뷰어에게 "아직 작업 중인 PR입니다"라는 의도를 분명히 전달할 수 있어요.

WIP 커밋과 Draft PR을 함께 사용하면, 작업 중인 기능도 팀과 안심하고 공유할 수 있어요.

참고

• AngularJS Git Commit Message Conventions