느낌 있는 Commit Message 작성하기
Commit Message
커밋(Commit)은 프로젝트 내의 어떠한 파일들에 변화가 있는 시점을 메시지와 함께 저장하는 기능입니다. 커밋 시점은 개발자마다 다릅니다만, 개인적으로는 코드를 기능별(Feature)로 쪼개서 수시로 커밋하는 것을 선호하는 편입니다. 한 번에 여러가지를 해 놓은 이후 커밋하는 것보다, 특정 기능이나 역할 변경에 대해서만 커밋을 남기면, 이후 코드 리뷰가 용이하고 해당 부분만 언급하기도 좋습니다. 만약 너무 많은 커밋으로 인해 로그(Log)가 지저분할 때는 Merge나 Rebase 명령으로로 정리하면 됩니다.
좋은 커밋 메시지

위 사진은 Alibaba Fusion이라는 곳의 저장소에서 가져온 커밋 히스토리입니다. 이 외에도 대형 서비스를 운영하고 있는 기업들의 깃허브에서 커밋 기록을 보면, 대부분 일관되고 직관적인 내용으로 메시지를 작성해 놓은 것을 확인할 수 있습니다. 이처럼 개발은 보통 혼자 하는 것이 아니기 때문에, 좋은 커밋 메시지를 남기는 것이 협업의 효율을 증진시키기 위해서라도 정말 중요합니다. 그렇다면 느낌 있는 커밋 메시지를 작성하기 위해서는 어떻게 해야 할까요?
좋은 커밋 메시지를 작성하기 위한 여러 방법론이 공개되어 있는데, 이들 중 일부를 정리해 봤습니다.
#
# Commit Message 기본 구조
#
<type>(<scope>): <subject>
<blank line>
<body>
<blank line>
(<footer>)
[ Subject ] type (커밋 종류)
- feat: 새로운 기능 추가
- fix: 버그 수정
- docs: 문서 수정
- style: 코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등)
- design: 사용자 UI 디자인 변경 (CSS 등)
- test: 테스트 코드, 리팩토링 (Test Code)
- refactor: 리팩토링 (Production Code)
- build: 빌드 파일 수정
- ci: CI 설정 파일 수정
- perf: 성능 개선
- chore: 자잘한 수정이나 빌드 업데이트
- rename: 파일 혹은 폴더명을 수정만 한 경우
- remove: 파일을 삭제만 한 경우
요즘은 정보 압축을 위해 이모지(gitmoji)를 사용하는 커밋 컨벤션도 있습니다.
[ Subject ] scope
- 선택사항이며, 변경된 부분을 직접적으로 표기합니다.
- EX) 함수가 변경되었으면 함수명, 메소드가 추가되었으면 클래스명 기입 등
[ Subject ] subject
- 첫 글자는 대문자로 입력합니다.
- 마지막에는 .(period)을 찍지 않습니다.
- 영문 기준 최대 50자를 넘지 않습니다.
- 제목은 명령문의 형태로 작성합니다. (동사원형 사용)
[ Body ]
- 각 줄은 최대 72자를 넘지 않도록 합니다.
- 어떻게 변경했는지보다, 무엇을 변경했고, 왜 변경했는지를 설명합니다.
[ Footer ]
- 선택사항이며, 관련된 이슈를 언급합니다. Ex) Fixes: #1, #2
- 주로 Closes(종료), Fixes(수정), Resolves(해결), Ref(참고), Related to(관련) 키워드를 사용합니다.
저는 개인 저장소에 커밋할 때는 '[feat] XX 구현', '[fix] XX 수정' 등으로 간단하게 작성합니다.
마무리하며
저는 영어를 잘하는 편이 아니라, 커밋 메시지를 작성할 때 어떻게 작성해야 할 지 항상 고민이 많았습니다. 하지만 커밋 메시지 작성에 대한 여러 방법론을 살펴 보고, 다양한 저장소의 커밋 히스토리들을 보면 엄청 어려운 단어가 사용된 메시지는 많지 않은 것을 알 수 있었습니다. 그래도 Implement, Update, Simplify 등 자주 등장하는 단어들이 있기 때문에, 이런 것들은 미리 알아두고 사용하시면 좋을 것 같습니다.
그래도 영어 공부 열심히 해 두면 좋겠지요 💦

References 📖
'🌈 기술스택 > Git' 카테고리의 다른 글
Stash로 변경 이력 임시 저장하기 (0) | 2021.10.24 |
---|---|
Merge와 Rebase 알아보기 (0) | 2021.10.24 |
프로젝트를 멋지게 설명하는 README.md (0) | 2021.09.25 |
Branch의 종류와 사용법 (0) | 2021.09.25 |
코드 관리를 위한 Git & GitHub (0) | 2021.09.25 |
댓글
이 글 공유하기
다른 글
-
Merge와 Rebase 알아보기
Merge와 Rebase 알아보기
2021.10.24브랜치를 하나로 합치는 방법 🤔 Git을 통해 프로젝트를 진행하다 보면 기능별로 브랜치를 만들어 구현하게 됩니다. 그리고 완성이 된 브랜치는 별다른 문제가 없다면, 상위 브랜치에 병합을 해줄 수 있습니다. Git에서는 병합을 위한 명령어로 merge가 있습니다. merge는 병합하고자 하는 브랜치의 상위 브랜치로 이동한 후, git merge 명령으로 수행할 수 있습니다. 서로 다른 브랜치에서 같은 파일을 수정했을 때 발생하는 충돌(Conflict)과 같은 문제가 없다면, 브랜치들을 정상적으로 병합해 줍니다. 그리고 git log 명령으로 커밋 히스토리를 확인해보면, 다음과 같이 병합이 잘 된 것을 확인할 수 있습니다. 브랜치를 따서 작업한 후 병합을 했음에도 불구하고 로그 그래프가 깔끔하고, 병합과 관… -
프로젝트를 멋지게 설명하는 README.md
프로젝트를 멋지게 설명하는 README.md
2021.09.25README.md README.md 파일은 깃허브 저장소를 돌아다니다 보면 흔히 볼 수 있는 문서 파일입니다. 이 파일은 프로젝트의 내용을 설명하기 위해 사용하는 파일로써 프로젝트가 어떤 목적에 의해 개발되었는지, 어떻게 사용할 수 있는지 등을 적어 놓습니다. README 문서의 내용은 저장소의 메인 페이지에 노출되기 때문에, 다소 귀찮더라도 신경 써서 작성하는 것이 좋습니다. GitHub는 저장소 최초 생성 시, README 파일을 작성할 수 있도록 안내하고 있습니다. 잘 작성된 README 문서의 예시로 facebook React 저장소를 가져와 봤습니다. 링크를 타고 들어가 보면 사진 속 내용 외에도 더 많은 내용을 확인할 수 있는데, React 뿐만 아니라 깃허브에 등록되어 있는 대부분의 프로젝트… -
Branch의 종류와 사용법
Branch의 종류와 사용법
2021.09.25Git Branches Git Workflow는 수명이 항상 유지되는 메인 브랜치(master, develop)와 일정 기간 동안만 유지되는 보조 브랜치(feature, release, hofix) 총 5개의 브랜치를 사용합니다. 아래 그림은 "A Successful Git brancing model" 글에 첨부된 이미지를 가져온 것으로, 이보다 더 Git Workflow를 잘 설명한 그림은 없는 것 같습니다 😀 메인 브랜치 (Main Branch) < master branch > master 브랜치는 배포 가능한 상태만을 관리하며, 커밋할 때는 태그를 사용해 배포(Release) 번호를 기록합니다. 위의 Workflow를 이용한 협업에서 작업한 결과물을 서브 브랜치가 아닌, master에 바로 올려 버… -
코드 관리를 위한 Git & GitHub
코드 관리를 위한 Git & GitHub
2021.09.25Git & GitHub Git은 컴퓨터 파일의 변경 사항을 추적하고, 여러 명의 사용자들과 해당 파일들을 공유하고, 수정할 수 있도록 도와주는 분산 버전 관리 시스템(Distributed Version Control System)입니다. 각 클라이언트와 서버는 추적하고 있는 파일의 마지막 변경 사항(스냅샷)만을 저장하지 않고, 저장소(디렉토리)와 함께 모든 히스토리(변경 내역)를 복제합니다. 그렇기 때문에 서버에서 문제가 발생하더라도, 분산되어 있는 클라이언트 중 하나를 통해 기존 상태를 완벽하게 복원할 수 있습니다. Git은 이와 같은 특성을 가지고 있기에 파일의 버전 관리가 용이하고, 각 버전을 통한 백업도 가능하며, 다른 개발자들과의 협업까지 가능합니다. 보통 Git을 통한 파일의 버전 관리는 주로…
댓글을 사용할 수 없습니다.