📌 Intro
우테코를 시작하면서 혼자 개발했을 때는 고려하지 않았던 부분들을 상당히 많이 고려하게 되었다. 그 중 하나가 Git 커밋 메시지다. 다른 분들의 커밋 메시지를 보면 구조가 정해져있으며 가독성이 좋은 것을 볼 수 있었다. 일단 슬랙에서 공유해주신 udacity commit convention을 따라가보려고 한다.
📌 Commit Message Structure
커밋 메시지는 세개의 다른 구조로 이루어져있고 공백으로 이루어진 행으로 구분된다. 전체적인 구조는 다음과 같다.
- type : 어떤 의도로 커밋했는지를 type에 작성한다. type의 종류는 아래서 설명할 것이다.
- subject : 최대 50글자가 넘지 않도록 하고 마침표는 찍지 않는다. 영문으로 표기하는 경우 과거시제보다 현재시제를 사용하여 명령문으로 작성하며 첫 글자는 대문자로 표기한다.
- body : 긴 설명이 필요한 경우 작성한다. 어떻게 했는지가 아니라 무엇을 왜 했는지 작성한다. 최대 75글자를 넘지 않도록 한다. 본문과 구분하기 위해 한 칸을 띄워 작성한다.
- footer : issue tracker ID를 명시하고 싶은 경우 작성한다. (선택사항이다.)
📌 Commit Message Type
커밋 메시지 타입은 다음과 같다.
- feat : 새로운 기능 추가
- fix : 버그 수정
- docs : 문서 수정
- style : 코드 포맷팅, 세미콜론 누락 등 코드 변경이 없는 경우
- refactor : 코드 리팩토링의 경우
- test : 테스트 코드 추가 및 수정
- chore : 빌드 업무 수정한 경우
📌 Example Commit Message
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영어라서 굉장히 읽기 싫었지만 간단하게 정리하면 다음과 같다.
제목은 50글자 이내로 요약해서 적어라.
더 추가적인 설명이 필요한경우 72자로 작성하라. 이 때 요약과 본문을 구분하는 빈 라인은 중요하다.
커밋이 해결하는 문제에 대해 왜 했는지 작성하라.
issue tracker를 작성하고 싶은 경우 Resolves: #123 See also: #456, #789 와 같이 작성하라.
위 예시는 너무 일반적이지 않으니 실제로 우테코 다른 분들이 작성하신 커밋 메시지를 보면 다음과 같다.
feat(Problem1): Add function for page validity check
chore(Problem1): Fix typo in Problem1.kt
fix(Problem1): Fix Error in makeBigNumber function정말 가독성 좋게 작성하셨다고 생각이 든다.. 앞으로 위에 정리한 컨벤션을 신경쓰면서 커밋 메시지를 작성하는 습관을 들여야겠다.
📌 참고
[1] https://siyoon210.tistory.com/56
[2] https://seolahchloe.tistory.com/entry/GitHub-깃-커밋-메세지-컨벤션-Git-Commit-Message-Convention
[3] https://udacity.github.io/git-styleguide/
[4] https://gist.github.com/stephenparish/9941e89d80e2bc58a153
📌 Intro
우테코를 시작하면서 혼자 개발했을 때는 고려하지 않았던 부분들을 상당히 많이 고려하게 되었다. 그 중 하나가 Git 커밋 메시지다. 다른 분들의 커밋 메시지를 보면 구조가 정해져있으며 가독성이 좋은 것을 볼 수 있었다. 일단 슬랙에서 공유해주신 udacity commit convention을 따라가보려고 한다.
📌 Commit Message Structure
커밋 메시지는 세개의 다른 구조로 이루어져있고 공백으로 이루어진 행으로 구분된다. 전체적인 구조는 다음과 같다.
- type : 어떤 의도로 커밋했는지를 type에 작성한다. type의 종류는 아래서 설명할 것이다.
- subject : 최대 50글자가 넘지 않도록 하고 마침표는 찍지 않는다. 영문으로 표기하는 경우 과거시제보다 현재시제를 사용하여 명령문으로 작성하며 첫 글자는 대문자로 표기한다.
- body : 긴 설명이 필요한 경우 작성한다. 어떻게 했는지가 아니라 무엇을 왜 했는지 작성한다. 최대 75글자를 넘지 않도록 한다. 본문과 구분하기 위해 한 칸을 띄워 작성한다.
- footer : issue tracker ID를 명시하고 싶은 경우 작성한다. (선택사항이다.)
📌 Commit Message Type
커밋 메시지 타입은 다음과 같다.
- feat : 새로운 기능 추가
- fix : 버그 수정
- docs : 문서 수정
- style : 코드 포맷팅, 세미콜론 누락 등 코드 변경이 없는 경우
- refactor : 코드 리팩토링의 경우
- test : 테스트 코드 추가 및 수정
- chore : 빌드 업무 수정한 경우
📌 Example Commit Message
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영어라서 굉장히 읽기 싫었지만 간단하게 정리하면 다음과 같다.
제목은 50글자 이내로 요약해서 적어라.
더 추가적인 설명이 필요한경우 72자로 작성하라. 이 때 요약과 본문을 구분하는 빈 라인은 중요하다.
커밋이 해결하는 문제에 대해 왜 했는지 작성하라.
issue tracker를 작성하고 싶은 경우 Resolves: #123 See also: #456, #789 와 같이 작성하라.
위 예시는 너무 일반적이지 않으니 실제로 우테코 다른 분들이 작성하신 커밋 메시지를 보면 다음과 같다.
feat(Problem1): Add function for page validity check
chore(Problem1): Fix typo in Problem1.kt
fix(Problem1): Fix Error in makeBigNumber function정말 가독성 좋게 작성하셨다고 생각이 든다.. 앞으로 위에 정리한 컨벤션을 신경쓰면서 커밋 메시지를 작성하는 습관을 들여야겠다.
📌 참고
[1] https://siyoon210.tistory.com/56
[2] https://seolahchloe.tistory.com/entry/GitHub-깃-커밋-메세지-컨벤션-Git-Commit-Message-Convention
[3] https://udacity.github.io/git-styleguide/
[4] https://gist.github.com/stephenparish/9941e89d80e2bc58a153
