Commit Message를 활용한 Git log 관리

Git

Commit Message를 활용한 Git log 관리

신림쥐 2024. 5. 22. 14:03

728x90

개요

협업 시 Git 커밋 메시지를 일관되게 관리하는 것은 매우 중요합니다. Conventional Commits는 커밋 메시지에 일정한 규칙을 적용해 Git log를 체계적이고 명확하게 관리할 수 있도록 도와주는 명세입니다.

이 문서에서는 Conventional Commits의 기본 규칙과 함께, 이를 기반으로 Git log를 효율적으로 관리하는 방법을 안내합니다.

Conventional Commits

Conventional Commits는 다음과 같은 구조를 가진 커밋 메시지 표준입니다.

이력 추적이 용이: git log, changelog 자동화 시 유리
자동 릴리스와 통합: semantic-release 등과 연동 가능
팀원 간 커뮤니케이션 개선: 커밋 메시지만 보고도 변경사항 이해 가능

Conventional Commits 형식

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

<타입>[적용 범위(선택 사항)]: [커밋메시지]

[본문(선택 사항)]

[꼬리말(선택 사항)]

예시)

feat(auth): 로그인 기능 추가
fix(ui): 버튼 클릭 시 이벤트 중복 처리 해결
docs(readme): 프로젝트 설명 추가
fix: member of values optional in ViewPropTypes
refactor: subsystem X for readability
update: getting started documentation
remove: deprecated methods
release: version 1.0.0
merge: pull request #123 from user/branch

<description> 작성 규칙

제목은 영문 기준 50자 , 한글 기준 25자 이내
제목과 본문을 빈 행으로 한 줄 띄워 분리하기
제목은 명령문, 부정명령문 형식 사용
제목 첫글자를 대문자로 작성
제목 끝에 . 금지
동명사보다 명사를 사용 (ing X)
본문은 영문 기준 72자 , 한글 기준 36자 마다 개행

<type> 키워드

커밋 분류용으로 커밋의 변경 목적을 명확하게 표현하는 목적입니다. git log나 changelog 자동화 도구들이 이 정보를 이용해 의미 있는 이력 목록을 만들 수 있습니다.

feat

새로운 기능 추가

fix

보통 올바르지 않은 동작(버그)을 고친 경우 사용

docs

문서 관련 수정 (README 등)

style

코드 포맷팅 (세미콜론 등), 기능 변경 없음

modify

코드 또는 파일 이름 변경 및 이동, 삭제 (move, remove, rename 포함)

refactor

기능, 페이지 등 전면 수정

update

문서나 리소스, 라이브러리 등 개정이나 버전 업데이트가 있을 때 사용

test

테스트 코드 추가 또는 수정 (add 포함)

chore

기타 변경사항 (빌드 설정 등)

이슈 관련 키워드

GitHub에서 커밋 메시지나 PR 설명에 이슈 번호를 참조하거나 자동 종료하고 싶을 때 사용합니다.

// 위 커밋은 fix라는 타입으로 오류 수정
fix(payment): 카드 결제 에러 해결 

// 102번 이슈를 자동으로 닫음
Fixes #102

이슈 관련 키워드 작성 규칙

반드시 #이슈번호 형식으로 작성해야 인식됩니다. (fixes #12)
커밋 메시지 본문이나 PR 본문에 적어야 합니다.
이슈는 병합(Merge) 될 때 닫히며, PR만 열려 있는 상태에서는 닫히지 않아요.
여러 개의 이슈도 동시에 닫을 수 있습니다:

closes #10, resolves #11, fixes #12

키워드	기능
close / closes / closed	이슈를 닫음
fix / fixes / fixed	버그를 고치고 이슈를 닫음
resolve / resolves / resolved	이슈를 해결하고 닫음
ref	참고
related to	참고
see also	참고

Conventional Commits 기반 Git log 조회

Conventional Commits 규칙에 따라 커밋 메시지를 작성하면, git log 명령어로 이력을 보다 명확하게 확인할 수 있습니다.

기본 로그 출력

$ git log

필터링된 로그 출력

git log --grep="^feat" --oneline

pretty 적용하여 log 조회하기

git log --pretty=format:"%h %ad | %s" --date=short

git log --pretty=format:"- $s(%h) - %s (%cd)" > CHANGELOG.md

pretty 확장 옵션

%H: 커밋 해시
%h: 축약된 커밋 해시
%T: 트리 해쉬
%t: 축약된 트리 해시
%P: 부모 해시들
%p: 축약된 부모 해시들
%an: 저자 이름
%aN: 저자 이름 (존칭)
%ae: 저자 이메일
%aE: 저자 이메일 (존칭)
%al: 저자 이메일 local-part (the part before the @ sign)
%aL: 저자 local-part (see %al) respecting .mailmap, see git-shortlog[1] or git-blame[1])
%ad: 저자 날짜 (format respects --date= option)
%aD: 저자 날짜, RFC2822 style
%ar: 저자 날짜, 상대적인
%at: 저자 날짜, UNIX timestamp
%ai: 저자 날짜, ISO 8601-like format
%aI: 저자 날짜, strict ISO 8601 format
%as: 저자 날짜, short format (YYYY-MM-DD)
%ah: 저자 날짜, human style (like the --date=human option of git-rev-list[1])
%cn: 커미터 이름
%cN: 커미터 이름 (존칭)
%ce: 커미터 이메일
%cE: 커미터 이메일 (존칭)
%cl: 커미터 이메일 local-part (the part before the @ sign)
%cL: 커미터 local-part (see %cl) 존칭
%cd: 커미터 날짜 (format respects --date= option)
%cD: 커미터 날짜, RFC2822 style
%cr: 커미터 날짜, relative
%ct: 커미터 날짜, UNIX timestamp
%ci: 커미터 날짜, ISO 8601-like format
%cI: 커미터 날짜, strict ISO 8601 format
%cs: 커미터 날짜, short format (YYYY-MM-DD)
%ch: 커미터 날짜, human style
%d: 참조 이름
%D: " (", ")"처럼 래핑 없는 참조 이름
%S: 커맨드 라인상에서 제공하는 참조이름 (= git log --source), git log에서만 동작
%e: 인코딩
%s: 주제
%f: 파일 이름에 적합한 정리된 제목 줄
%b: 바디
%B: raw body (unwrapped subject and body)
%N: commit notes
%GG: 서명된 커밋에 대한 GPG의 raw verification message
%G?: 좋은 (유효한) 서명을 위해 "G"표시
%GS: 서명된 커밋의 서명자 이름 표시
%GK: 서명된 커밋에 서명하는 데 사용되는 키 표시
%GF: show the fingerprint of the key used to sign a signed commit
%GP: 서명된 커밋에 서명하는 데 사용된 키의 지문 표시
%GT: 서명된 커밋에 서명하는 데 사용되는 키의 신뢰 수준을 표시
%gD: reflog selector
%gd: shortened reflog selector; %gD와 동일, 하지만 참조 이름 부분은 사람의 가독성을 위해 단축되었습니다. (그래서 refs/heads/master는 master가 됨)
%gn: 신분 이름을 reflog
%gN: 신분 이름을 reflog (존칭)
%ge: 신원 이메일 거부
%gE: 신원 이메일 거부 (존칭)
%gs: 주제를 reflog

728x90