커밋 메시지 모범 사례

프로젝트 이력을 되돌아본다고 상상해 보세요. 명확한 커밋 메시지가 없다면 빈 항목만 있는 일기를 읽는 것과 같습니다!

좋은 커밋 메시지는 변경한 이유, 변경된 내용, 변경 사항이 프로젝트에 미치는 방식을 이해하는 데 매우 중요합니다. 이를 통해 여러분과 팀이 코드를 디버깅하고 검토하며 새 구성원을 빠르게 적응시킬 수 있습니다.

표준 깃 커밋 메시지는 크게 두 부분으로 구성됩니다.

• 제목 줄: 변경 사항을 요약하는 간결한 한 줄입니다.
• 본문(선택 사항): 제목과 빈 줄로 구분되는 더 자세한 설명입니다.

이메일과 비슷하다고 생각해 보세요. 빠르게 훑어볼 수 있는 제목 줄과 세부 정보를 담는 본문으로 구성됩니다.

제목 줄은 가장 중요한 부분입니다. 다음 규칙을 따르세요.

• 간결하게 작성: 50~72자 이내로 유지합니다.
• 명령형 사용: 현재 시제의 동사로 시작합니다(예: "Added feature"나 "Adding feature"가 아니라 "Add feature").
• 첫 글자 대문자 사용: 가독성을 위한 일반적인 관례입니다.
• 마침표 사용 금지: 제목 줄을 마침표로 끝내지 않습니다.

좋은 제목 줄과 나쁜 제목 줄의 예를 살펴보겠습니다.

• 좋은 예: Fix: broken login button
• 좋은 예: Feat: implement user profile page
• 나쁜 예: Fixed a bug in the login system that was causing issues. (너무 길고 과거형임)
• 나쁜 예: updates (너무 모호함)

명확하고 간결하게 작성하세요!

커밋 본문에서는 변경의 동기, 맥락, 코드만으로는 분명하지 않은 세부 정보를 설명합니다.

제목 줄만으로 설명하기에 부족한 변경을 다룰 때 사용하세요. 깃 도구에서 더 쉽게 읽을 수 있도록 줄 길이를 약 72자로 줄바꿈해 작성합니다.

본문을 작성할 때는 다음을 지키세요.

• 변경한 내용뿐 아니라 변경한 이유를 설명합니다.
• 트레이드오프나 설계 결정을 설명합니다.
• 잠재적인 부작용이나 주의해서 살펴볼 영역을 언급합니다.
• 제목과 본문 사이에 빈 줄을 둡니다.

이렇게 하면 나중에 읽는 사람에게 유용한 맥락을 제공할 수 있습니다.

완전하고 잘 구성된 커밋 메시지는 다음과 같은 형태입니다.

많은 팀은 제목 줄을 유형 접두사로 시작하는 규칙을 채택합니다. 이를 통해 변경 사항을 빠르게 분류할 수 있습니다.

일반적인 접두사는 다음과 같습니다.

• feat: (새 기능)
• fix: (버그 수정)
• docs: (문서 변경)
• style: (코드 스타일 변경, 기능 변경 없음)
• refactor: (코드 리팩터링)
• test: (테스트 추가)
• chore: (유지 관리, 빌드 과정 변경)

프로젝트 관리 시스템(예: GitHub Issues, Jira)에서 커밋을 관련 이슈나 풀 리퀘스트에 연결하는 것은 좋은 습관입니다.

일반적으로 본문에 Closes #123, Fixes #45 또는 Refs #67과 같은 문구를 커밋 메시지에 포함하면 됩니다. 그러면 코드 변경 사항이 추적 중인 작업에 자동으로 연결됩니다.

모범 사례에 따르면 잘 작성된 깃 커밋 메시지는 어떤 특징을 갖추어야 하나요?

잘 작성된 커밋 메시지가 프로젝트의 명확성과 협업에 매우 중요하다는 것을 배웠습니다. 이러한 모범 사례를 따르면 프로젝트 이력이 소중한 자료가 됩니다!

• 제목 줄을 간결하게 작성하고 명령형을 사용합니다.
• 본문을 사용해 변경한 '이유'를 설명합니다.
• 분류를 위해 유형 접두사 사용을 고려합니다.
• 맥락을 제공할 수 있도록 이슈나 풀 리퀘스트에 연결합니다.

즐거운 커밋 되세요!