[기본기]Git Commit Message Style Guide

DevelSopher·2021년 7월 28일
2

Git Commit Message의 스타일 가이드는 왜 필요할까?

그렇지 않아도 복잡한 Git, 왜 가이드를 지키며 작성해야 하는것일까?
그냥 편하게 내 맘대로 작성하면 안될까?

정답은 ❌

우리가 Git을 쓰는 이유는 바로 여러 사람과 작업을 하면서 작업의 진행상황을 쉽게 파악하기 위함이다.

심지어 혼자 작업함에 있어서도 어떠한 변경사항이 있었는지 파악하기 위함이다.

바로git message을 보고 직관적으로 판단할 수 있다.
그래서 우리는 직관적이며 일관성있는 약속을 바탕으로 message 작성을 해야한다.

good message style guide === ! 구성원간의 불필요한 의사소통

여기서 좋은 룰은 무엇일까?

딱히 정답은 없다. 통일된 원칙을 바탕으로 일관성이 있으면 된다.
스타일에는 여러 종류가 있지만, 현재 Udacity Style이 가장 널리 쓰이는 방식이다.
(Udacity Style 바탕으로 스타일 가이드를 소개하겠다.)

메시지의 구조

크게 세 부분으로 나뉘어 진다.

type(scope(선택)) : Subject -- Header(필수)
body -- (선택)
footer -- (선택)

각 부분은 한 줄의 공백으로 구분한다.
tip) git log 사용시 git log --oneline 입력하면 message의 header 부분만 깔끔하게 나온다!

메시지 구조 자세히 설명

Type

Type은 항상 영문 소문자로 작성

  • feat : 새로운 기능을 추가하거나, 기존 기능을 요구사항 변경으로 인해 변경한 경우
  • fix : 버그를 수정한 경우
  • docs : 문서(주석) 추가/수정의 경우, 직접적인 코드의 변화 없이 문서만 추가 수정 했을 때
  • style : UI를 추가/수정하거나, 스타일 관련 작업의 경우
  • refactor : 기능의 변경 없이, 코드를 리팩토링 한 경우
  • test : 테스트 코드를 추가/수정한 경우
  • chore : 기능/테스트, 문서, 스타일, 리팩토링 외에 배포, 빌드와 같이 프로젝트의 기타 작업들에 대해 추가/수정한 경우

Scope

생략 가능

  • 커밋의 해당하는 파일명과 확장자까지 적는것이 일반적이다
    ex) feat(router or App.js): A~~~

Subject

  • 제목은 50글자 내로 제한
  • 제목 첫 글자는 대문자로 작성(영어)
  • 제목 끝에 마침표 넣지 않기
  • 영문작성시, 명령문을 사용하며 과거형 금지
  • 국문작성시, 구문으로 작성

Body

Header로 표현가능하다면 생략가능한 부분이다
제목에서 하지 못한 커밋의 상세 내역을 작성한다

  • 본문으 72글자 내로 제한
  • How 보다는, whatwhy를 설명

생략가능
어떤 이슈에서 왔는지에 대한 참조정보들을 추가하는 용도
(#issueNumber)

cf)한개의 issue에 해당할 시 Header 부분에 작성

ex) Type(scope): Subject(#issueNumber)

그 외에는 footer에 이슈 번호와 라벨을 추가한다.

여기서 라벨의 종류에는
Resolve,closes,Fixes,see also가 있는데,
github의 경우 라벨의 종류에 따라 이슈를 닫을 수 있다.

profile
💎다듬고 연마하자👑

0개의 댓글