지금까지 git add하여 staging area에 commit할 파일들을 등록하였다.
이제 repo에 commit 하여 보자.
git commit 을 입력하면
현재 staging area에 들어있는 파일들이 commit되면서 에디터( 내 경우에는 sublime text)가 뜬다.
거기에 commit message를 작성하면 된다.
(또는 git commit -m "Commit message" 와 같이 에디터 없이 직접 작성할수도 있다.)
Git Message Style Guide
commit message 의 구조
type: subject
body
footer
크게 위와 같이 title(type:subject), body(선택), footer(선택)의 세 가지로 나뉜다.
1. type: 다음과 같은 것들이 올 수 있다.
feat: 새로이 추가된 feature
fix: 버그 fix
docs: documentation의 변화
style: formatting, 빼먹은 세미콜론 등(코드 변화는 없는 경우)
refactor: refactoring(결과의 변화 없이 코드 구조를 새로이 다듬는 것) 내용
test: 테스트 추가, 리팩터링 테스트 등(production code의 변화 없이)
chore: 빌드 업데이트, package manager 설정(production code 변화 없이)
2. subject: 50자를 넘지 않고 마침표 찍지 않는다. 동사의 명령형을 사용한다.
그래서 type:subject를 합쳐서 title로 하는 경우의 예는 다음과 같다.
예) feat: Summarize changes in around 50 characters or less
3. body: 제목 외에 부가 설명이 필요할 때 선택적으로 작성한다.
각 줄은 72자가 넘지 않도록 하며 제목과 한줄 띄어서 작성한다.
여기에는 what, why를 설명해야 하며 how를 설명해서는 안된다.
4. footer: reference issue tracker ID가 필요시 작성.
전체 작성 실례>
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
댓글 없음:
댓글 쓰기