커밋 규칙

커밋을 관리하는 규칙들을 정리하고 있어요.

이는 권고사항이 아닌, 바인드 내 모든 개발에서 필수적인 사항이므로 꼭 지켜야 해요.

커밋 규칙에 오류가 있다면 ci 과정에서 막아져 Main, Master 에 병합이 불가능하니 꼭 지켜주세요.

기본 형식

기본적인 커밋 형식은 다음과 같아요.

Terminal

$ <type>: <subject>

type

type은 어떤 커밋인가? 를 정의하는 예약어에요.

아래 예약어 외에는 추가적으로 사용이 불가능하니 기억해주세요.

type	설명	예시
feat	새로운 기능을 추가했음을 의미해요	feat: 백그라운드 푸시알람 구현
fix	버그 수정을 했음을 의미해요	fix: 토큰 만료 처리 오류 수정
docs	레포지토리 내 문서를 수정했음을 의미해요	docs: 인증 api docs 업데이트
style	코드 포맷팅을 수정했을때를 의미해요(ui 변경이 아닙니다!)	style: prettier 적용
refactor	코드에 대한 리팩토링을 했음을 의미해요	refactor: 유저 서비스 책임 분리
chore	빌드,설정변경을 했음을 의미해요 (코드 로직의 경우는 해당되지 않습니다.)	chore: netty socket 의존성 추가
perf	코드 자체의 성능을 개선했음을 의미해요	perf: 캐싱 최적화
ci	ci/cd 설정을 의미해요	ci: git action workflow 추가
revert	커밋을 되돌렸음을 의미해요	revert: feat: 푸시알림 구현
merge	브랜치를 병합했음을 의미해요	merge: main

subject

subject는 이 커밋의 주요 내용이 무엇인가? 를 정의하는 문장이에요.

subject를 작성하는데는 다음과 같은 규칙을 꼭 지켜야 해요.

한국어, 영어 모두 사용 가능해요.
띄어쓰기 또한 가능해요.
DX 경험 향상을 위해 문장식이 아닌 개조식으로 작성해요.
마침표나 쉼표는 사용하지 마세요.
50자 이내로 작성하세요.

좋은 예시

커밋 형식의 좋은 예시는 다음과 같아요.

plaintext

feat: 웹뷰 브릿지 카메라 API 구현
fix: 로그인 시 토큰 갱신 오류 수정
docs: 사용자 API 엔드포인트 문서 추가
refactor: 알림 서비스 MSA로 분리

나쁜 예시

커밋 형식의 나쁜 예시는 다음과 같아요.

plaintext

추가 → type, subject 누락
feat: 기능 추가 → 너무 모호함
feat: 로그아웃 버튼 추가 #82 → 이슈번호를 커밋에 포함함
feat(mobile): 로그인 버튼 클릭했을 때 화면이 잘 나오도록 수정했어요. → 너무 김, 과거형
fix: bug fixed. → 구체적이지 않음, 마침표

커밋 단위

커밋은 기능이 다 완료되고 나서, 한꺼번에 하는것이 아니에요.

코드의 형상관리, 품질관리를 위해 주기적으로 커밋을 해야해요.

각 커밋들의 단위는 커밋을 되돌려도 프로그램이 정상적으로 작동되는가? 를 기준으로 삼고 커밋해주세요.

fix류는 해당 규칙 기준을 제외합니다.

하나의 기능을 다 추가해야만 커밋을 할 수 있는게 아니라, 기능을 개발하는 과정에서도 추가한 기준에 따라, 커밋을 주기적으로 해주세요.

금지사항

의미없는 메시지는 금지됩니다. ex) fix: asdsadasds 관련없는 여러 작업을 한꺼번에 커밋하는것도 금지됩니다.;

FAQ

Q1. 여러 파일을 수정했는데 타입이 다르면?

A: 커밋을 분리하세요. git add -p로 부분 스테이징 활용

Q2. 타입이 애매할 때는?

A: 가장 주요한 변경사항을 기준으로 판단

Q3. 이미 잘못 작성한 커밋은?

A: git commit --amend로 수정 (Push 전에만 가능)

Q4. 기존 프로젝트는 언제부터 적용?

A: 새로운 커밋부터 바로 적용, 과거 커밋은 수정 불필요