개인 프로젝트를 할 때엔 보통 Gitmoji 사용해서 커밋을 남기는데,
보통 협업을 할 때엔 Gitmoji보단 그냥 커밋 컨벤션 규칙을 세워서 하기 때문에
나중에 참고할 수 있도록 정리할 예정이다.
그리고 Gitmoji를 쓰면서 커밋을 남기고있는데 좀 헷갈려서 다시 정리해볼 것이다.
커밋 컨벤션
🤔 커밋 컨벤션은 왜 필요할까?
개인 프로젝트 경우에는 나만 알아보면 그만이지만.. 협업을 할 경우에는 누가, 어떤 코드를 작성하고 수정했는지 알아보기 위한 수단이라고 볼 수 있다. 규칙을 세워놓고 거기에 따라 작성하면 나중에 커밋내역을 찾기도 수월해지고 이해하기 편하기 때문!
커밋 메시지 구조
type : subject
body
footer
아직 구조만 보면 뭔지 모르겠으므로 하나씩 살펴보자!
type rule
타입에는 태그가 들어가는 부분이다. 보통 태그에는 정해진 규칙이 있는데
| Type | 설명 |
| Feat | 새로운 기능 추가 |
| Fix | 버그 수정 |
| Docs | 문서 수정 |
| Style | 스타일 관련 기능 (코드 포맷팅, 세미콜론 누락 등) |
| Refactor | 코드 리팩토링 |
| Test | 테스트 코드 추가 |
| Chore | 빌드 업무 수정, 패키지 매니저 수정 |
이렇게들 많이 쓰는 것 같다.
근데 정해진 건 아니기 때문에 여기서 따로 추가하거나 바꿔서 타입 규칙을 세울 수 있다.
그래서 나는 옛날에 지인분이 공유해주신 커밋 메세지를 참고해서 사용할 예정이다.
| Type | 설명 | 참고사항 |
| Feat | 기능 추가 | 기능 당 최초 한 번만 사용 |
| Build | 라이브러리 세팅/업데이트 | 라이브러리 설치 최초 한 번만 사용 |
| Update | 라이브러리 버전 업데이트/커스텀 | |
| Config | Config 파일 설정 | |
| Remove | 파일 삭제 | |
| Fix | 기능 에러 수정 | |
| HotFix | 치명적인 버그 수정 | main 브랜치에 바로 반영 |
| Style | UI 관련 CSS 수정 | |
| Chore | 단순 코드 수정 | 주석, 줄 바꿈, 임포트문, 세미콜론 등등.. |
| Revise | 기능 추가나 덧붙임을 위한 수정 | |
| Typo | 오타 수정 | |
| Modify | 기능 변경 있는 코드 개선/변경 | |
| Refactor | 기능 변경 없는 코드 개선 | |
| Asset | 이미지, 폰트 | 리소스 파일 |
| Docs | 문서 작성 |
subject rule
- 제목은 최대 50글자 넘지 않는다.
- 마침표 및 특수기호를 사용하지 않는다.
- 영어로 작성 시 첫 글자는 대문자로 작성한다.
- 명령문을 사용한다.
- 간결하고 요점적으로 서술한다.
body rule
- 한 줄당 72자 내로 작성한다.
- 상세하게 작성한다.
- 어떻게 보다는 무엇을, 왜 변경했는지 작성한다.
footer rule
유형 : #이슈 번호의 형식으로 작성한다.
이슈 트래커 ID를 작성한다.
여러개의 이슈 번호는 ,로 구분
| issue tracker | 설명 |
| Fixes | 이슈 수정중 |
| Resolves | 이슈 해결 |
| Ref | 참조할 이슈가 있을 때 |
| Related to | 해당 커밋에 관련된 이슈 번호 |
커밋 템플릿
# 제목은 최대 50글자까지 아래에 작성: ex) Feat: Add Key mapping
# 본문은 아래에 작성
# 꼬릿말은 아래에 작성: ex) Github issue #23
# --- COMMIT END ---
# <타입> 리스트
# feat : 기능 (새로운 기능)
# fix : 버그 (버그 수정)
# refactor : 리팩토링
# design : CSS 등 사용자 UI 디자인 변경
# comment : 필요한 주석 추가 및 변경
# style : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
# docs : 문서 수정 (문서 추가, 수정, 삭제, README)
# test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
# chore : 기타 변경사항 (빌드 스크립트 수정, assets, 패키지 매니저 등)
# init : 초기 생성
# rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만 한 경우
# remove : 파일을 삭제하는 작업만 수행한 경우
# ------------------
# 제목 첫 글자를 대문자로
# 제목은 명령문으로
# 제목 끝에 마침표(.) 금지
# 제목과 본문을 한 줄 띄워 분리하기
# 본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
# 본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# ------------------
# <꼬리말>
# 필수가 아닌 optioanl
# Fixes :이슈 수정중 (아직 해결되지 않은 경우)
# Resolves : 이슈 해결했을 때 사용
# Ref : 참고할 이슈가 있을 때 사용
# Related to : 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
# ex) Fixes: #47 Related to: #32, #21
커밋 컨벤션 적용법
1. 해당 프로젝트 루트 디렉토리에 .gitmessage.txt 파일 생성
해당 파일 생성 후 위의 템플릿을 복붙한다.
#은 주석이므로 신경쓰지말자!
2. 터미널 열어서 아래 명령어 입력
git config --local commit.template .gitmessage.txt
기본적으로 local에서만 템플릿이 쓰이도록 설정해놨다.
모든 프로젝트에도 커밋 메시지 템플릿을 적용하고 싶다면 config 뒤에 있는 --local을 바꿔주면 된다.
- --system: 해당 시스템에 있는 모든 사용자와 모든 저장소에 적용되는 설정 파일
- --global: 해당 사용자에게만 적용되는 설정 파일(내 로컬에서 커밋하는 모든 프로젝트에서 동일한 템플릿이 적용됨)
- --local: 현재 작업 중인 저장소의 git 디렉토리에 있는 파일을 찾는다. 이 파일은 해당 저장소에만 적용된다.
3. 커밋하기
이제 터미널에 변경사항을 추가하고 git commit을 입력하면 저렇게 뜬다.
커밋 메시지 예시
Style : contents07 반응형 작업
배너부분 모바일 화면에서 레이아웃이 깨지므로 반응형 작업 진행
Resolves: #123
이런식으로 작업해주면 된다.
body와 footer는 선택사항이므로 위의 title만 적어도 무방하다.
다 작성했으면 git push ㄱㄱ
그런데 난.. 개인 프로젝트 위주로 진행하였고
실무할 때도 따로 터미널에서 커밋을 하지 않았다.
보통은 여기서 바로바로 커밋했기 때문에.. (터미널 열기 귀찮음 ㅜ)
어차피 나중에 풀리퀘스트 보낼 때 이슈나 바뀐 내용을 적어줬기 때문에.. ㅎ_ㅎ
근데 귀여운 이모지 쓰는 분들이 있어서 살펴봤는데 Gitmoji라는 아주 귀여운게 존재했었잖아!!
패키지 설치해서 직접 터미널에 쓸 수 있지만..
귀찮아서 익스텐션에서 설치했다 헿
Gitmoji
깃모지(Gitmoji)는 깃(Git)을 사용하는 프로젝트에서 커밋 메시지에 이모지를 사용하여 의미를 전달하는 것을 의미
깃모지 설치 방법
익스텐션에서 gitmoji 검색
설치하고
커밋하는 곳 드가면 이모지가 생겼을 것이다!
누르면 저렇게 뜬다.
상황에 맞는 깃모지 고르고 타이포 써주면 끝 ㅎㅎ
옵션이 영어라 헷갈리므로 한국어로 정리해보면..
깃모지 컨벤션
| 이모지 | 설명 | 원문 |
| 🎨 | 코드의 구조/형태 개선 | Improve structure / format of the code. |
| ⚡️ | 성능 개선 | Improve performance. |
| 🔥 | 코드/파일 삭제 | Remove code or files. |
| 🐛 | 버그 수정 | Fix a bug. |
| 🚑️ | 긴급 수정 | Critical hotfix. |
| ✨ | 새 기능 | Introduce new features. |
| 📝 | 문서 추가/업데이트 | Add or update documentation. |
| 🚀 | 배포 | Deploy stuff. |
| 💄 | UI 스타일링 추가/업데이트 | Add or update the UI and style files. |
| 🎉 | 프로젝트 시작 | Begin a project. |
| ✅ | 테스트 추가/업데이트 또는 테스트 통과 | Add, update, or pass tests. |
| 🔒️ | 보안 이슈 수정 | Fix security or privacy issues. |
| 🔐 | 암호화 추가 또는 업데이트 | Add or update secrets. |
| 🔖 | 릴리즈 / 버전 태그 | Release / Version tags. |
| 🚨 | 컴파일러 / 린터 경고 수정 | Fix compiler / linter warnings. |
| 🚧 | 작업중인 코드 | Work in progress. |
| 💚 | CI 빌드 수정 | Fix CI Build. |
| ⬇️ | 의존성 다운그레이드 | Downgrade dependencies. |
| ⬆️ | 의존성 업그레이드 | Upgrade dependencies. |
| 📌 | 의존성을 특정 버전에 고정 | Pin dependencies to specific versions. |
| 👷 | CI 빌드 시스템 추가 또는 업데이트 | Add or update CI build system. |
| 📈 | 분석 또는 추적 코드 추가/업데이트 | Add or update analytics or track code. |
| ♻️ | 코드 리팩토링 | Refactor code. |
| ➕ | 의존성 추가 | Add a dependency. |
| ➖ | 의존성 삭제 | Remove a dependency. |
| 🔧 | 설정 파일 추가/업데이트 | Add or update configuration files. |
| 🔨 | 개발 스크립트 추가/업데이트 | Add or update development scripts. |
| 🌐 | 국제화와 지역화 | Internationalization and localization. |
| ✏️ | 오타 수정 | Fix typos. |
| 💩 | 똥코드 작성 | Write bad code that needs to be improved. |
| ⏪️ | 변경사항 되돌리기 | Revert changes. |
| 🔀 | 브랜치 병합(머지) | Merge branches. |
| 📦️ | 컴파일된 파일 또는 패키지 추가/업데이트 | Add or update compiled files or packages. |
| 👽️ | 외부 API 변경으로 인한 코드 업데이트 | Update code due to external API changes. |
| 🚚 | 파일, 경로, 라우트 등 리소스 이동 혹은 이름변경 | Move or rename resources (e.g.: files, paths, routes). |
| 📄 | 라이센스 추가/업데이트 | Add or update license. |
| 💥 | 호환성을 깨뜨리는 변경사항 | Introduce breaking changes. |
| 🍱 | 리소스 파일 추가/업데이트 | Add or update assets. |
| ♿️ | 접근성 개선 | Improve accessibility. |
| 💡 | 소스 코드 내 주석 추가/업데이트 | Add or update comments in source code. |
| 🍻 | 술먹고 코드 작성(????) | Write code drunkenly. |
| 💬 | 텍스트나 문자열 추가/업데이트 | Add or update text and literals. |
| 🗃️ | 데이터베이스 관련 변경 수행 | Perform database related changes. |
| 🔊 | 로그 추가/업데이트 | Add or update logs. |
| 🔇 | 로그 제거 | Remove logs. |
| 👥 | 기여자 추가/업데이트 | Add or update contributor(s). |
| 🚸 | 사용자 경험/사용성 개선 | Improve user experience / usability. |
| 🏗️ | 아키텍쳐 변경 | Make architectural changes. |
| 📱 | 반응형 디자인 작업 | Work on responsive design. |
| 🤡 | 테스트를 위한 목업 | Mock things. |
| 🥚 | 이스터 에그 추가/업데이트 | Add or update an easter egg. |
| 🙈 | .gitignore 파일 추가/업데이트 | Add or update a .gitignore file. |
| 📸 | 스냅샷 추가/업데이트 | Add or update snapshots. |
| ⚗️ | 실험 | Perform experiments. |
| 🔍️ | 검색 엔진 최적화 개선 | Improve SEO. |
| 🏷️ | 타입 추가/업데이트 | Add or update types. |
| 🌱 | 시드 파일 추가/업데이트 | Add or update seed files. |
| 🚩 | 기능 플래그 추가/업데이트/제거 | Add, update, or remove feature flags. |
| 🥅 | 에러 처리 | Catch errors. |
| 💫 | 애니메이션 전환 추가/업데이트 | Add or update animations and transitions. |
| 🗑️ | 삭제해야 할 코드 삭제될 에정 표시 | Deprecate code that needs to be cleaned up. |
| 🛂 | 인증,역할,권한 관련 코드 작업 | Work on code related to authorization, roles and permissions. |
| 🩹 | 중요하지 않은 이슈 수정 | Simple fix for a non-critical issue. |
| 🧐 | 데이터 탐색/검사 | exploration/inspection. |
| ⚰️ | 죽은 코드 제거 | Remove dead code. |
| 🧪 | 실패하는 테스트 추가 | Add a failing test. |
| 👔 | 비즈니스 로직 추가/업데이트 | Add or update business logic. |
| 🩺 | 상태 검사 추가/업데이트 | Add or update healthcheck. |
| 🧱 | 인프라 관련 변경 | Infrastructure related changes. |
| 🧑💻 | 개발자 경험 개선 | Improve developer experience. |
| 💸 | 후원이나 돈 관련 인프라 추가 | Add sponsorships or money related infrastructure. |
| 🧵 | 멀티쓰레드나 동시성 관련 코드 추가/업데이트 | Add or update code related to multithreading or concurrency. |
| 🦺 | 검증 관련 코드 추가/업데이트 | Add or update code related to validation. |
와.. 정리해놓으니까 진짜 많네...
근데 실상 쓰이는 건 몇 개 안될 것 같다.
아무튼! 내가 작성한 커밋 컨벤션과 깃모지는 정답이 아니기 때문에
팀 상황에 맞게 규칙을 세우면 좋을 것 같다!
참고
https://doooodle932.tistory.com/180
개인 프로젝트를 할 때엔 보통 Gitmoji 사용해서 커밋을 남기는데,
보통 협업을 할 때엔 Gitmoji보단 그냥 커밋 컨벤션 규칙을 세워서 하기 때문에
나중에 참고할 수 있도록 정리할 예정이다.
그리고 Gitmoji를 쓰면서 커밋을 남기고있는데 좀 헷갈려서 다시 정리해볼 것이다.
커밋 컨벤션
🤔 커밋 컨벤션은 왜 필요할까?
개인 프로젝트 경우에는 나만 알아보면 그만이지만.. 협업을 할 경우에는 누가, 어떤 코드를 작성하고 수정했는지 알아보기 위한 수단이라고 볼 수 있다. 규칙을 세워놓고 거기에 따라 작성하면 나중에 커밋내역을 찾기도 수월해지고 이해하기 편하기 때문!
커밋 메시지 구조
type : subject
body
footer
아직 구조만 보면 뭔지 모르겠으므로 하나씩 살펴보자!
type rule
타입에는 태그가 들어가는 부분이다. 보통 태그에는 정해진 규칙이 있는데
| Type | 설명 |
| Feat | 새로운 기능 추가 |
| Fix | 버그 수정 |
| Docs | 문서 수정 |
| Style | 스타일 관련 기능 (코드 포맷팅, 세미콜론 누락 등) |
| Refactor | 코드 리팩토링 |
| Test | 테스트 코드 추가 |
| Chore | 빌드 업무 수정, 패키지 매니저 수정 |
이렇게들 많이 쓰는 것 같다.
근데 정해진 건 아니기 때문에 여기서 따로 추가하거나 바꿔서 타입 규칙을 세울 수 있다.
그래서 나는 옛날에 지인분이 공유해주신 커밋 메세지를 참고해서 사용할 예정이다.
| Type | 설명 | 참고사항 |
| Feat | 기능 추가 | 기능 당 최초 한 번만 사용 |
| Build | 라이브러리 세팅/업데이트 | 라이브러리 설치 최초 한 번만 사용 |
| Update | 라이브러리 버전 업데이트/커스텀 | |
| Config | Config 파일 설정 | |
| Remove | 파일 삭제 | |
| Fix | 기능 에러 수정 | |
| HotFix | 치명적인 버그 수정 | main 브랜치에 바로 반영 |
| Style | UI 관련 CSS 수정 | |
| Chore | 단순 코드 수정 | 주석, 줄 바꿈, 임포트문, 세미콜론 등등.. |
| Revise | 기능 추가나 덧붙임을 위한 수정 | |
| Typo | 오타 수정 | |
| Modify | 기능 변경 있는 코드 개선/변경 | |
| Refactor | 기능 변경 없는 코드 개선 | |
| Asset | 이미지, 폰트 | 리소스 파일 |
| Docs | 문서 작성 |
subject rule
- 제목은 최대 50글자 넘지 않는다.
- 마침표 및 특수기호를 사용하지 않는다.
- 영어로 작성 시 첫 글자는 대문자로 작성한다.
- 명령문을 사용한다.
- 간결하고 요점적으로 서술한다.
body rule
- 한 줄당 72자 내로 작성한다.
- 상세하게 작성한다.
- 어떻게 보다는 무엇을, 왜 변경했는지 작성한다.
footer rule
유형 : #이슈 번호의 형식으로 작성한다.
이슈 트래커 ID를 작성한다.
여러개의 이슈 번호는 ,로 구분
| issue tracker | 설명 |
| Fixes | 이슈 수정중 |
| Resolves | 이슈 해결 |
| Ref | 참조할 이슈가 있을 때 |
| Related to | 해당 커밋에 관련된 이슈 번호 |
커밋 템플릿
# 제목은 최대 50글자까지 아래에 작성: ex) Feat: Add Key mapping
# 본문은 아래에 작성
# 꼬릿말은 아래에 작성: ex) Github issue #23
# --- COMMIT END ---
# <타입> 리스트
# feat : 기능 (새로운 기능)
# fix : 버그 (버그 수정)
# refactor : 리팩토링
# design : CSS 등 사용자 UI 디자인 변경
# comment : 필요한 주석 추가 및 변경
# style : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
# docs : 문서 수정 (문서 추가, 수정, 삭제, README)
# test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
# chore : 기타 변경사항 (빌드 스크립트 수정, assets, 패키지 매니저 등)
# init : 초기 생성
# rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만 한 경우
# remove : 파일을 삭제하는 작업만 수행한 경우
# ------------------
# 제목 첫 글자를 대문자로
# 제목은 명령문으로
# 제목 끝에 마침표(.) 금지
# 제목과 본문을 한 줄 띄워 분리하기
# 본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
# 본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# ------------------
# <꼬리말>
# 필수가 아닌 optioanl
# Fixes :이슈 수정중 (아직 해결되지 않은 경우)
# Resolves : 이슈 해결했을 때 사용
# Ref : 참고할 이슈가 있을 때 사용
# Related to : 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
# ex) Fixes: #47 Related to: #32, #21
커밋 컨벤션 적용법
1. 해당 프로젝트 루트 디렉토리에 .gitmessage.txt 파일 생성
해당 파일 생성 후 위의 템플릿을 복붙한다.
#은 주석이므로 신경쓰지말자!
2. 터미널 열어서 아래 명령어 입력
git config --local commit.template .gitmessage.txt
기본적으로 local에서만 템플릿이 쓰이도록 설정해놨다.
모든 프로젝트에도 커밋 메시지 템플릿을 적용하고 싶다면 config 뒤에 있는 --local을 바꿔주면 된다.
- --system: 해당 시스템에 있는 모든 사용자와 모든 저장소에 적용되는 설정 파일
- --global: 해당 사용자에게만 적용되는 설정 파일(내 로컬에서 커밋하는 모든 프로젝트에서 동일한 템플릿이 적용됨)
- --local: 현재 작업 중인 저장소의 git 디렉토리에 있는 파일을 찾는다. 이 파일은 해당 저장소에만 적용된다.
3. 커밋하기
이제 터미널에 변경사항을 추가하고 git commit을 입력하면 저렇게 뜬다.
커밋 메시지 예시
Style : contents07 반응형 작업
배너부분 모바일 화면에서 레이아웃이 깨지므로 반응형 작업 진행
Resolves: #123
이런식으로 작업해주면 된다.
body와 footer는 선택사항이므로 위의 title만 적어도 무방하다.
다 작성했으면 git push ㄱㄱ
그런데 난.. 개인 프로젝트 위주로 진행하였고
실무할 때도 따로 터미널에서 커밋을 하지 않았다.
보통은 여기서 바로바로 커밋했기 때문에.. (터미널 열기 귀찮음 ㅜ)
어차피 나중에 풀리퀘스트 보낼 때 이슈나 바뀐 내용을 적어줬기 때문에.. ㅎ_ㅎ
근데 귀여운 이모지 쓰는 분들이 있어서 살펴봤는데 Gitmoji라는 아주 귀여운게 존재했었잖아!!
패키지 설치해서 직접 터미널에 쓸 수 있지만..
귀찮아서 익스텐션에서 설치했다 헿
Gitmoji
깃모지(Gitmoji)는 깃(Git)을 사용하는 프로젝트에서 커밋 메시지에 이모지를 사용하여 의미를 전달하는 것을 의미
깃모지 설치 방법
익스텐션에서 gitmoji 검색
설치하고
커밋하는 곳 드가면 이모지가 생겼을 것이다!
누르면 저렇게 뜬다.
상황에 맞는 깃모지 고르고 타이포 써주면 끝 ㅎㅎ
옵션이 영어라 헷갈리므로 한국어로 정리해보면..
깃모지 컨벤션
| 이모지 | 설명 | 원문 |
| 🎨 | 코드의 구조/형태 개선 | Improve structure / format of the code. |
| ⚡️ | 성능 개선 | Improve performance. |
| 🔥 | 코드/파일 삭제 | Remove code or files. |
| 🐛 | 버그 수정 | Fix a bug. |
| 🚑️ | 긴급 수정 | Critical hotfix. |
| ✨ | 새 기능 | Introduce new features. |
| 📝 | 문서 추가/업데이트 | Add or update documentation. |
| 🚀 | 배포 | Deploy stuff. |
| 💄 | UI 스타일링 추가/업데이트 | Add or update the UI and style files. |
| 🎉 | 프로젝트 시작 | Begin a project. |
| ✅ | 테스트 추가/업데이트 또는 테스트 통과 | Add, update, or pass tests. |
| 🔒️ | 보안 이슈 수정 | Fix security or privacy issues. |
| 🔐 | 암호화 추가 또는 업데이트 | Add or update secrets. |
| 🔖 | 릴리즈 / 버전 태그 | Release / Version tags. |
| 🚨 | 컴파일러 / 린터 경고 수정 | Fix compiler / linter warnings. |
| 🚧 | 작업중인 코드 | Work in progress. |
| 💚 | CI 빌드 수정 | Fix CI Build. |
| ⬇️ | 의존성 다운그레이드 | Downgrade dependencies. |
| ⬆️ | 의존성 업그레이드 | Upgrade dependencies. |
| 📌 | 의존성을 특정 버전에 고정 | Pin dependencies to specific versions. |
| 👷 | CI 빌드 시스템 추가 또는 업데이트 | Add or update CI build system. |
| 📈 | 분석 또는 추적 코드 추가/업데이트 | Add or update analytics or track code. |
| ♻️ | 코드 리팩토링 | Refactor code. |
| ➕ | 의존성 추가 | Add a dependency. |
| ➖ | 의존성 삭제 | Remove a dependency. |
| 🔧 | 설정 파일 추가/업데이트 | Add or update configuration files. |
| 🔨 | 개발 스크립트 추가/업데이트 | Add or update development scripts. |
| 🌐 | 국제화와 지역화 | Internationalization and localization. |
| ✏️ | 오타 수정 | Fix typos. |
| 💩 | 똥코드 작성 | Write bad code that needs to be improved. |
| ⏪️ | 변경사항 되돌리기 | Revert changes. |
| 🔀 | 브랜치 병합(머지) | Merge branches. |
| 📦️ | 컴파일된 파일 또는 패키지 추가/업데이트 | Add or update compiled files or packages. |
| 👽️ | 외부 API 변경으로 인한 코드 업데이트 | Update code due to external API changes. |
| 🚚 | 파일, 경로, 라우트 등 리소스 이동 혹은 이름변경 | Move or rename resources (e.g.: files, paths, routes). |
| 📄 | 라이센스 추가/업데이트 | Add or update license. |
| 💥 | 호환성을 깨뜨리는 변경사항 | Introduce breaking changes. |
| 🍱 | 리소스 파일 추가/업데이트 | Add or update assets. |
| ♿️ | 접근성 개선 | Improve accessibility. |
| 💡 | 소스 코드 내 주석 추가/업데이트 | Add or update comments in source code. |
| 🍻 | 술먹고 코드 작성(????) | Write code drunkenly. |
| 💬 | 텍스트나 문자열 추가/업데이트 | Add or update text and literals. |
| 🗃️ | 데이터베이스 관련 변경 수행 | Perform database related changes. |
| 🔊 | 로그 추가/업데이트 | Add or update logs. |
| 🔇 | 로그 제거 | Remove logs. |
| 👥 | 기여자 추가/업데이트 | Add or update contributor(s). |
| 🚸 | 사용자 경험/사용성 개선 | Improve user experience / usability. |
| 🏗️ | 아키텍쳐 변경 | Make architectural changes. |
| 📱 | 반응형 디자인 작업 | Work on responsive design. |
| 🤡 | 테스트를 위한 목업 | Mock things. |
| 🥚 | 이스터 에그 추가/업데이트 | Add or update an easter egg. |
| 🙈 | .gitignore 파일 추가/업데이트 | Add or update a .gitignore file. |
| 📸 | 스냅샷 추가/업데이트 | Add or update snapshots. |
| ⚗️ | 실험 | Perform experiments. |
| 🔍️ | 검색 엔진 최적화 개선 | Improve SEO. |
| 🏷️ | 타입 추가/업데이트 | Add or update types. |
| 🌱 | 시드 파일 추가/업데이트 | Add or update seed files. |
| 🚩 | 기능 플래그 추가/업데이트/제거 | Add, update, or remove feature flags. |
| 🥅 | 에러 처리 | Catch errors. |
| 💫 | 애니메이션 전환 추가/업데이트 | Add or update animations and transitions. |
| 🗑️ | 삭제해야 할 코드 삭제될 에정 표시 | Deprecate code that needs to be cleaned up. |
| 🛂 | 인증,역할,권한 관련 코드 작업 | Work on code related to authorization, roles and permissions. |
| 🩹 | 중요하지 않은 이슈 수정 | Simple fix for a non-critical issue. |
| 🧐 | 데이터 탐색/검사 | exploration/inspection. |
| ⚰️ | 죽은 코드 제거 | Remove dead code. |
| 🧪 | 실패하는 테스트 추가 | Add a failing test. |
| 👔 | 비즈니스 로직 추가/업데이트 | Add or update business logic. |
| 🩺 | 상태 검사 추가/업데이트 | Add or update healthcheck. |
| 🧱 | 인프라 관련 변경 | Infrastructure related changes. |
| 🧑💻 | 개발자 경험 개선 | Improve developer experience. |
| 💸 | 후원이나 돈 관련 인프라 추가 | Add sponsorships or money related infrastructure. |
| 🧵 | 멀티쓰레드나 동시성 관련 코드 추가/업데이트 | Add or update code related to multithreading or concurrency. |
| 🦺 | 검증 관련 코드 추가/업데이트 | Add or update code related to validation. |
와.. 정리해놓으니까 진짜 많네...
근데 실상 쓰이는 건 몇 개 안될 것 같다.
아무튼! 내가 작성한 커밋 컨벤션과 깃모지는 정답이 아니기 때문에
팀 상황에 맞게 규칙을 세우면 좋을 것 같다!
참고
https://doooodle932.tistory.com/180
