기존에는 혼자서 여러가지 프로젝트들을 진행하면서 마음대로 git의 commit메세지를 작성해왔는데, Wanted의 프리온보딩 프론트엔드 챌린지에 강의를 들으며 여러명이 함께 프로젝트를 진행하기 위해서는 암묵적으로 통일된 간결한 commit메세지 작성을 통해 다른 사람들도 쉽게 어떤 부분이 변경되었는지 빠른 파악이 가능하도록 만드는 것에 대한 중요성을 다시 한번 생각해보게 되었다.

아직 다수와 함께 진행하는 큰 프로젝트를 참여해보지는 않았지만 미리 좋은 git commit메세지를 작성하는 습관을 기르기 위해 수강생들에게 강사님께서 참고하라고 공유해주신 git commit메세지 작성 규칙 관련 글 속 여러 규칙들을 직접 이 글을 작성하며 공부해보았다. 앞으로는 잘 참고하여 좋은 git commit메세지들로 학습기록을 남겨보아야겠다.

🟡 커밋 메세지 규칙

1. 동사보다는 명사를 사용하자
→ 동사를 명사화해 만드는 장황한 문장보다는 간결하게 명사로 표현하는 것이 좋다.

2. 관사 사용하지 않기
→ 반드시 필요한 경우를 제외하고는 a, an, the와 같은 관사는 사용하지 않는 것이 좋다.

3. 부정문 Don't사용하기
→ 일반적으로 commit메세지를 작성할 때 'A를 사용해'라는 식의 명령문 형태로 작성하므로, 반대 이야기를 하려면 'A를 사용하지마', 즉 'Don't use'의 형태로 작성해야 한다.

//예시
Do not return list if there are too many crashes

오타수정은 Correct misspelled text처럼 긴 표현이 아닌 Fix typo라고 간단히 표현해줄 수 있다.

🟡 좋은 커밋 메시지를 위한 영어 단어 목록

1. Fix(올바르지 않은 동작을 고친 경우에 사용)

📍 Fix A (= A를 수정합니다.)

Fix changelog entry
Fix stat cache
Fix search path

📍 Fix A in B (= B의 A를 수정합니다.)
→ 가장 자주 사용되는 패턴!

Fix build warning in node_report.cc
Fix calculation in process.uptime()

📍 Fix A which B, Fix A that B (= B절인 A를 수정합니다.)
→ which, that과 같은 관계대명사로 A를 부연설명. 무엇을 수정한 것인지 보다 자세히 설명하기 위해 사용함.

Fix incorrect type which makes animated gifs not loop forever on device
Fix crash that happens when a component throws an exception that contains a null message

📍 Fix A to B, Fix A to be B (= B를 위해 A를 수정합니다.)
→ 왜 수정하는지를 추가로 설명하기 위해 사용함.

Fix inability to remove 'Disabled' state from AccessibilityStates
Fix HTTP connection timeout callback to be appropriately called

📍 Fix A so that B (= A를 수정해서 B가 되었습니다.)
→ ‘Fix A to B’와 의미는 비슷하나, 어감이 살짝 다름. 고쳐진 B의 상태가 보다 강조된다.

Fix react-native init --help so that it doesn't return undefined
Fix Android 28's inverted ScrollView so that momentum is in the proper direction

📍 Fix A where B (= B처럼 발생하는 A를 수정했습니다.)
→ 여기서 A는 보통 ‘issue’, ‘error’, ‘crash’등이 들어갑니다. B는 문제가 발생한 모습을 적는다.

Fix case where content of inline views didn't get relaid out
Fix case where inline view is visible even though it should have been truncated

📍 Fix A when B (= B일때 발생하는 A를 수정했습니다.)
→ 여기서 A는 보통 ‘issue’, ‘error’, ‘crash’등이 들어갑니다. B는 문제가 발생한 상황을 적는다.

Fix accidental showing of Modal when visible prop is undefined or null
Fix crash when removing root nodes

2. ADD(코드나 테스트, 예제, 문서 등의 추가가 있을 때 사용)

📍 Add A (= A를 추가합니다.) → 추가하는 경우는 대부분 목표나 목적이 명시되므로 사용빈도 낮음.

Add ERR_INSPECTOR_COMMAND error

📍 Add A for B (= B를 위해 A를 추가합니다.)

Add missing includes for vtune build
Add test for dynamically enabling node.async_hooks tracing

📍 Add A to B (= B에 A를 추가합니다.)

Add error description to Image onError callback
Add displayName to ActivityIndicator

3. REMOVE(코드의 삭제가 있을 때 사용)

‘Clean’이나 ‘Eliminate’를 사용하며, 보통 A 앞에 ‘unnecessary’, ‘useless’, ‘unneeded’, ‘unused’, ‘duplicated’가 붙는 경우가 많다.

📍 Remove A (= A를 삭제합니다.)

Remove unneeded .gitignore entries
Remove unused variable

📍 Remove A from B (= B에서 A를 삭제합니다.)

Remove absolute path parameter from transformers
Remove trailing slash from origin header if no port is specified

4. USE(특별히 무언가를 사용해 구현을 하는 경우 사용)

📍 Use A (= A를 사용합니다.) → ‘사용하였음’을 이야기 할 때는 대체적으로 목적이 필요하기 때문에 사용빈도 낮음.

Use more stable cast where possible

📍 Use A for B (= B에 A를 사용합니다.)

Use fake MessageEvent for port.onmessage
Use object writer for thrown errors

📍 Use A to B (= B가 되도록 A를 사용합니다.)

use common operations to define browser globals
use triggerReport() to handle signals

📍 Use A in B (= B에서 A를 사용합니다.)

Use same parameter name in node_report.cc
Use TextLegend example in Android as well

📍 Use A instead of B (= B 대신 A를 사용합니다.)

Use babel runtime instead of relying on global babelHelpers and regenerator

5. REFACTOR(전면 수정이 있는 경우 사용)

📍 Refactor A (= A를 전면수정합니다.)

Refactor argument validation
Refactor thread life cycle management

6. SIMPLIFY(복잡한 코드를 단순화 할 때 사용)

Refactor의 성격이 강하나 이보다는 약한 수정의 경우 이용하면 좋습니다.

📍 Simplify A (= A를 단순화합니다.)

Simplify heap space iteration
Simplify TriggerNodeReport()

7. UPDATE(개정이나 버전 업데이트가 있을 때 사용)

Fix와는 달리 Update는 잘못된 것을 바로잡는 것이 아니라는 점에 주의해야 함.
원래도 정상적으로 동작하고 있었지만, 수정, 추가, 보완을 한다는 개념.
코드보다는 주로 문서나 리소스, 라이브러리등에 사용.

📍 Update A to B (= A를 B로 업데이트 합니다. / A를 B하기 위해 업데이트 합니다.)

Update acorn to 6.1.0

Update repo docs to use HTTPS
Update app icons to match recent Android releases

8. IMPROVE(향상이 있을 때 사용)

호환성, 테스트 커버리지, 성능, 검증 기능, 접근성 등 다양한 것들이 목적이 될 수 있음.

📍 Improve A (= A를 향상시킵니다.)

Improve Unicode handling
Improve test coverage in perf_hooks

9. MAKE(기존 동작의 변경을 명시할 때 사용)

📍 Make A B (= A를 B하게 만듭니다.)

• config object를 read-only로 만듭니다.
• floating patch 메시지에 더 많은 정보가 담기도록 만듭니다.
• ViewPropTypes의 값들을 옵셔널하게 만듭니다.
• read()를 유저가 원한다면 무기한으로 호출되도록 만듭니다.
• IsolateData가 ArrayBuffer를 저장하도록 만듭니다.

→ 모두 기존의 동작을 바꾼 것들입니다. 새롭게 뭔가를 만들었을 때는 Make 대신, Add를 사용해야 합니다.

Make config object read-only
make 'floating patch' message informational
Make values optional in ViewPropTypes

10. IMPLEMENT(코드가 추가된 정도보다 더 주목할 만한 구현체를 완성시켰을 때 사용)

📍 Implement A (= A를 구현합니다.)
→ ‘Add’에 비해 더 큰 단위의 코드 추가에 사용되며, 특히 모듈이나 클래스 등의 단위에 사용되기 때문에 특별히 목적을 부여 해주지 않아도 되는 경우가 많기 때문에 ‘Add’에 비해 to나 for가 함께 사용되는 경우가 적다.

Implement date object
Implement Image.defaultSource

📍 Implement A to B (= B를 위해 A를 구현합니다.)
→ 구현 목적을 설명할 필요가 있을 때에는 ‘to’를 사용.

Implement requiresMainQueueSetup in RCTTVNavigationEventEmitter to satisfy Xcode warning

출처 : ull.im 블로그 - 👉🏻 좋은 git commit 메시지를 위한 영어 사전 by Reid