[GitHub] Development log : 협업을 위한 git commit convention 깃허브 커밋메세지 쓰는방법

0

GITHUB

목록 보기
7/9
post-custom-banner

Udacity Git Commit Message Style Guide

여러사람들과 개발하다보니 커밋메세지의 중요성 또한 많이 느끼게 된다.


메세지의 구조

type : 어떤 의도로 커밋했는지를 type에 명시합니다. 자세한 사항은 아래서 설명하겠습니다.
subject : 최대 50글자가 넘지 않도록 하고 마침표는 찍지 않습니다. 영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기합니다.
body : 긴 설명이 필요한 경우에 작성합니다. 어떻게 했는지가 아니라, 무엇을 왜 했는지를 작성합니다. 최대 75자를 넘기지 않도록 합니다.
footer : issue tracker ID를 명시하고 싶은 경우에 작성합니다.


제목 작성법

1. 제목의 처음은 동사 원형으로 시작합니다.

2. 총 글자 수는 50자 이내로 작성합니다.

3. 마지막에 특수문자는 삽입하지 않습니다. 예) 마침표(.), 느낌표(!), 물음표(?)

4. 제목은 개조식 구문으로 작성합니다.


[English]

1. 첫 글자는 대문자로 작성합니다.

2. "Fix", "Add", "Change"의 명령어로 시작합니다.

한글로 제목을 작성하는 경우 다음의 규칙을 따릅니다.


[Korean]

1. "고침", "추가", "변경"의 명령어로 시작합니다.


태그 적는방법 ?

태그 뒤에는 ": "를 붙여 제목과 구별할 수 있도록 합니다.

  1. 기능
  2. 개선
  3. 그 외

기능

Feat: 새로운 기능을 추가할 경우
Fix: 버그를 고친 경우
Design: CSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE: 커다란 API 변경의 경우 (ex API의 arguments, return 값의 변경, DB 테이블 변경, 급하게 치명적인 버그를 고쳐야 하는 경우)

ex)
"Feat(navigation): "
"Fix(database): "


개선

Style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor: 프로덕션 코드 리팩토링, 새로운 기능이나 버그 수정없이 현재 구현을 개선한 경우
Comment: 필요한 주석 추가 및 변경


그 외

Docs: 문서를 수정한 경우
Test: 테스트 추가, 테스트 리팩토링 (프로덕션 코드 변경 없음)
Chore: 빌드 태스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 없음)
Rename: 파일 혹은 폴더명을 수정하는 경우
Remove: 사용하지 않는 파일 혹은 폴더를 삭제하는 경우


본문작성법

  1. 본문은 한 줄 당 72자 내로 작성합니다.
  2. 본문 내용은 양에 구애받지 않고 최대한 상세히 작성합니다.
  3. 본문 내용은 어떻게 변경했는지 보다 무엇을 변경했는지 또는 왜 변경했는지를 설명합니다.

꼬리말작성법

  1. 꼬리말은 optional이고 이슈 트래커 ID를 작성합니다.
  2. 꼬리말은 "유형: #이슈 번호" 형식으로 사용합니다.
  3. 여러 개의 이슈 번호를 적을 때는 쉼표로 구분합니다.
  4. 이슈 트래커 유형은 다음 중 하나를 사용합니다.
    - Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
    - Resolves: 이슈를 해결했을 때 사용
    - Ref: 참고할 이슈가 있을 때 사용
    - Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
    ex) Fixes: #45 Related to: #34, #23


커밋 메시지 Emoji는 한곳에 몰아넣어야겠다 :) !

profile
𝐁𝐚𝐜𝐤-𝐞𝐧𝐝 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫 (𝐒𝐖)
post-custom-banner

0개의 댓글