-
Notifications
You must be signed in to change notification settings - Fork 4
/
.gitmessage.txt
67 lines (61 loc) · 3.86 KB
/
.gitmessage.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
# <타입(<영역>)>: <주제>
# - 타입은 필수 작성. 해당 커밋의 성격을 나타내며 타입의 종류 중 하나만 선택, 영어 소문자로 시작
# - 영역은 필요 시 작성. 변경된 부분을 직접적으로 나타냄 ex) 🩹 Refactor(MemberService): loginMember 메소드 명을 login으로 수정
# - 주제는 필수 작성. 최대 50글자까지, 끝에 마침표 금지, 한글로 간단 명료하게 작성, 현재형 사용
# 바로 밑줄에 작성
# 바로 아래 한 줄 공백 유지 (머릿말과 본문의 분리를 위함)
################################
# <본문> - 필요시 작성. 한 줄당 최대 72자까지, 72자 초과시 줄바꿈, ”왜”, “무엇을 위해” 작업했는지에 초점을 맞춰 작성
# 바로 밑줄에 작성
# 바로 아래 한 줄 공백 유지 (본문과 바닥글의 분리를 위함)
################################
# <바닥글> - 필요시 작성
# 바로 밑줄에 작성 (이슈 해결 시에는 resolve: #99와 같이 작성)
#######🆁🅴🅼🅴🅱🅴🆁 🅼🅴######
# [타입 리스트]
# 🐞 Fix: 올바르지 않은 동작(버그)을 고친 경우
# 🌊 Feat: 새로운 기능을 추가한 경우
# ✨ Add: feat 이외의 부수적인 코드, 라이브러리 등을 추가한 경우, 새로운 파일(Component나 Activity 등)을 생성한 경우도 포함
# 🩹 Refactor: 내부 로직은 변경하지 않고 기존의 코드를 개선한 경우, 클래스명 수정&가독성을 위해 변수명을 변경한 경우도 포함
# 🗑️ Remove: 코드, 파일을 삭제한 경우, 필요 없는 주석 삭제도 포함
# 🚚 Move: fix, refactor 등과 관계 없이 코드, 파일 등의 위치를 이동하는 작업만 수행한 경우
# 🎨 Style: 내부 로직은 변경하지 않고 코드 스타일, 포맷 등을 수정한 경우, 줄 바꿈, 누락된 세미콜론 추가 등의 작업도 포함
# 💄 Design: CSS 등 사용자 UI 디자인을 추가, 수정한 경우
# 📝 Comment: 필요한 주석을 추가, 수정한 경우(❗ 필요 없는 주석을 삭제한 경우는 remove)
# 📚 Docs: 문서를 추가, 수정한 경우
# 🔧 Test: 테스트 코드를 추가, 수정, 삭제한 경우
# 🎸 Chore: 위 경우에 포함되지 않는 기타 변경 사항
# 🙈 gitignore: ignore파일 추가 및 수정
# ------------------
# [커밋 메시지 예시]
# 🐞 Fix: CardList 컴포넌트 클릭 시 공백으로 나오는 오류 수정
#
# 모바일 버전에서 CardList의 img 부분 클릭 시 공백으로 나오는 오류 수정.
# PC 버전은 이상 없음.
#
# resolve: #232
# ------------------
# [우리 팀이 지켜야 할 보편적 규칙]
# 1. 언어는 한국어를 사용한다.
# - 예외 사항) 최초 커밋 메시지는 “Initial commit”으로 한다.
# 2. 문장의 구성
# 1) 문장은 간결하게 구성한다.
# 2) 현재형을 사용한다.
# 3. 작성한 당사자가 아닌 제 3자가 이해할 수 있도록 작성한다.
# 4. 단순한 문장일수록 좋다.
# ------------------
# [우리 팀의 커밋 타이밍]
# - 의미 있는 코드의 변화가 있다면 커밋을 진행한다.
# - 의미가 있다면 사소한 것을 커밋 하는 것은 전혀 잘못된 것이 아니다.
# - 다만 의미 없는 잦은 커밋은 히스토리 추적에 불편함을 주므로 의미 없는 커밋은 자제한다.
# [Pull Requests 규칙]
# - 의미 없는 잦은 PR 요청은 자제한다.
# - 수정되거나 변경된 사항이 있다면, 설명은 자세하게 작성한다.
# [Code Review 규칙]
# - 다음의 경우에 맞게 리뷰한다.
# 1. 일관된 아키텍처를 유지하고 있는가에 대한 의견 제시
# 2. 다른 해결 방법에 대한 의견 제시
# 3. 버그가 발생할 수 있는 가능성 제시
# 4. 기술적인 지식, 노하우 공유
# 5. 히스토리 전달
################################