회사 프로젝트를 진행하면서 메시지가 담고 있는 의미에 대해서 종종 생각하게 되었습니다.
코드로 모든 걸 나타낼 수 있다면 가장 좋겠지만, 코드에 온전히 나의 의도를 담는 것은 쉽지 않습니다.
따라서, 가장 자주 사용하는 메시지인 Coimmit, Comment, Log의 작성법에 대해서 정리해보고자 합니다.
메시지를 잘 적는 것은 협업에서 반드시 필요한 기본적인 습관입니다. 기록으로 소통이 가능하기 때문입니다.
Commit Message
필요성
1. Git을 사용하면 반드시 커밋 메시지를 남기도록 되어있습니다. 그렇기 때문에 많은 개발자들은 의미없이 커밋 메시지를 적기도 합니다.
ex) "제발", "이번엔 성공" 등
2. 커밋메시지는 단순히 소스코드를 올리거나 억울함을 호소하기 위한 것이 아닙니다.
코드의 변경사항을 요약하는 Message
1. 협업과 효율성: 변경 내역을 쉽게 파악할 수 있어 서로 작업에 대한 이해를 높힐 수 있습니다.
2. 문제 해결: 문제 발생 시, 쉽게 디버깅이 가능합니다. 언제 어디서 문제가 발생했는지 쉽게 식별할 수 있습니다.
Commit Message Convention
정해진 규칙에 따라 메시지리를 기재하여 더욱 효율적인 프로젝트 환경을 만들 수 있습니다.
> 가독성이 높아져 불필요한 의사소통을 최소한으로 만듭니다.
> 다양한 Git 명령어(Git blame, revert, rebase, log)등을 효율적으로 사용 가능합니다.
커밋 메시지 작성 시 참고하면 좋은 7가지 규칙을 소개한 사이트입니다. 영어 기준으로 되어 있어서 조금 더 유연한 적용이 가능합니다.
1. 제목과 본문을 한 줄로 띄워 분리
2. 제목은 영문 기준 50자 이내
3. 제목 첫 글자는 대문자
4. 제목 끝에 마침표(.) 금지
5. 제목은 명령조
6. 본문은 영문 기준 72자마자 줄 바뀍
7. 본문은 어떻게보다 무엇을, 왜에 맞춰서 작성
위 7가지 규칙은 커밋메시지를 최대한 간결하고 일관성 있도록 쓰는 것을 강조합니다.
- 제목과 본문을 한 줄로 띄어 분리하게 되면 git log --oneline 명령어 시, 제목으로만 간단히 커밋 내용을 유추할 수 있습니다.
- Git의 Built-in Convention은 제목을 명령문으로 사용하고 있습니다. Merge bracnh 'feature'은 git에서 자동 실행하는 커밋 메시지의 기본값입니다. 이에 맞춰서 Release version 1.0.0과 같이 제목을 실행한다면 자연스럽게 Built-in Convention과 맞출 수 있습니다.
반드시 위 7가지 규칙을 넣어서 컨벤션을 작성할 필요는 없습니다. 그러나 컨벤션을 적용하면 어떤 수정사항이 있는 지 한 눈에 쉽게 알아 볼 수 있습니다.
| 컨벤션이 적용되지 않은 커밋 메시지 | 컨벤션이 적용된 커밋 메시지 |
 출처: 과거의 나 |
 출처: https://github.com/naver/egjs-flicking/commits/nightly |
커밋 메시지 구조
type: subject
body
footer- Type: 변경 사항의 유형, 아래 Type 영어 참조
- Subject: 변경 작업의 제목이나 간단한 요약, 대문자로 시작하고 마침표를 사용하지 않음
- (Option)Body: 작업 내용이 복잡하거나 상세한 내용을 남겨야 하는 경우에 작성. 무엇을 왜 고쳤는지에 대해서 상세하게 적음. 한 줄에 72자 이내
- (Option)Footer: 코드 작업과 관련 이슈 번호 또는 참고 링크 추가
예시
fix: 신규 가입 시 사용자 전화번호 공백 수정
- 사용자 전화번호가 12자리로 입력되면 정상적으로 표시
- 전화번호 자릿수가 11자리인 경우, 저장을 하지 않아 공백으로 표시하는 내용 수정
- ...
Resolves: #123456
타입을 적용하여 간단하게 커밋 메시지를 작성한 내용입니다. Type과 Subject은 필수로 입력하고 그 외에 Body, Footer는 필요한 경우에만 입력하면 됩니다.
최종적으로 위 내용들을 요약하여 커밋메시지 형태로 표현한 내용입니다.
feat: Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequenses of this
change? Here's the place to explain them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here
If you use an issue tracker, put references to them at the bottom,
like this:
Resolves: #123
See also: #456, #789
자주 쓰는 Type 영어
| 영어 단어 | 사용 패턴 | 비고 |
| fix | 올바르지 않은 동작을 고친 경우 | 오타수정: fix typo |
| feat | 새로운 기능 추가 또는 업데이트 | |
| add | 코드, 테스트, 예제, 문서 등 추가 | |
| remove | 코드 삭제 | clean, eliminate를 사용하기도 함 |
| comment | 주석 수정 및 삭제 | |
| refactor | 전면 수정이 있을 때, 코드만 개선 | |
| update | 개정이나 버전 업데이트가 있을 때 - 정상동작하고 있지만 수정/추가/보완하는 것 |
주로 문서, 리소스, 라이브러리 등 사용 docs: 문서 개정 |
| chore | 빌드, 패키지 관련 업데이트 | |
| test | 테스트 코드 추가 | |
| correct | 문법 오류, 타입 변경, 이름 변경 등 | 오타수정: fix type |
그 외
use(무언가를 사용해 구현), simplify(복잡한 코드 단순화), implement(구현체 완성), ensure(확실하게 보장되는 것을 명시, i문 등), prevent(특정한 처리를 막음), avoid(회피), verify(검증 코드 추가), improve(호환성 등 기능 향상), make(기존 동작 변경), allow(허용), rename(이름 변경), move(코드 이동), set(변수 값 변경 등 작은 수정), pass(파라메터를 넘기는 처리)
Commit을 해야하는 시기
너무 자주하게 되면 이슈 트래킹에 불편함을 겪을 수 있습니다. 정답은 없지만 의미있는 코드 변화가 생기면 커밋을 하는 것을 권장합니다.
1. 기능에 대한 테스트가 끝났을 때
2. 기능 기반으로 커밋
- 새로운 기능/작동하는 메소드 추가
3. 새로운 테스트 케이스 추가, 테스트 통과, 변수 이름 변경 등 의미있는 코드 변화가 있을 때
참고문헌
https://meetup.nhncloud.com/posts/106
'IT > 고찰' 카테고리의 다른 글
| Git과 SVN 고찰 (0) | 2024.06.19 |
|---|---|
| Log에 대한 고찰 (0) | 2023.08.25 |
| Comment에 대한 고찰 (0) | 2023.08.15 |