목차.
1. 커밋 메시지, 왜 규칙이 필요할까
2. 좋은 커밋 메시지를 작성하기 위한 규칙들
3. 좋은 커밋 메시지의 예
4. 커밋은 언제 하는 것이 좋을까
5. 좋은 커밋 방법에 대한 내 생각
커밋(commit)
의미 있는 변경 작업들을 저장소에 기록하는 동작
커밋 메시지, 왜 규칙이 필요할까
버전 변경사항 기록 시 일관성 없이 메시지를 작성하게 된다면 시각적 통일성을 떨어뜨리고 커밋 히스토리를 파악하는 데 어려움을 줄 수 있습니다. 특히 여러 명이서 협업할 경우에 더더욱 커밋 메시지 규칙은 중요해집니다.
잘 구성된 커밋 메시지는 협업하는 다른 개발자에게 그리고 미래의 나에게 변경사항에 대해 전달하는 가장 좋은 방법입니다.
좋은 커밋 메시지를 쓰게 됐을 때 아래와 같은 이점을 얻을 수 있습니다.
- 몇 달 또는 몇 년 전에 일이 발생한 이유를 이해할 수 있다.
- 변경사항에 대해 쉽게 파악할 수 있다.
⇒ 더 쉬운 코드 유지 보수, 더 나은 협업!
좋은 커밋 메시지를 작성하기 위한 규칙들
좋은 커밋 메시지를 작성하려면 아래 3가지를 고민해 봐야 합니다.
- Style - 마크업 구문, 줄바꿈 여백, 문법, 대문자, 구두점에 대한 규칙은 어떻게 정할까?
- Content - 커밋 메시지 본문에는 어떤 정보가 포함되어야 할까?
- Metadata - issue tracking IDs, pull request number 등은 어떻게 참조해야 할까?
처음부터 우리가 규칙을 만드는 것은 어렵겠지만, 다행히도 잘 정립된 규칙이 존재합니다.
지금까지 많은 개발자들은 좋은 커밋 방법에 대해 끊임없이 고민해왔고 오늘날 범용적으로 쓰이는 커밋 컨벤션이 나오게 되었습니다.
좋은 커밋 메시지를 작성하기 위한 규칙과 구조를 알아보겠습니다.
커밋 메시지의 7가지 규칙
- 제목과 본문을 빈 행으로 구분합니다.
- 제목을 50글자 이내로 제한합니다.
- 제목의 첫 글자는 대문자로 작성합니다.
- 제목의 끝에는 마침표를 넣지 않습니다.
- 제목은 명령문으로! 과거형을 사용하지 않습니다.
- 본문의 각 행은 72글자 내로 제한합니다.
- 어떻게보다는 무엇과 왜를 설명합니다.
커밋 메시지 구조
첫 줄은 변경 내용을 한 줄로 간단하게 요약하여 작성합니다. 자세한 내용은 <body>에 적습니다.
제목 줄
<type> : 변경 사항의 특징에 따라 적는다.
<scope> : 변경이 된 위치(클래스, 메서드 이름)를 적는다. (생략 가능)
<subject> : 변경 내용을 간단하게 요약해서 적는다.
<type>
<type>은 해당 커밋의 성격을 나타내며 아래 중 하나여야 합니다.
- feat : 새로운 기능을 추가하였을 때
- fix : 버그를 수정하였을 때
- style : 들여 쓰기, 세미콜론 등을 변경하였을 때
- refactor : 코드 리팩토링을 했을 때(기능의 변경은 없어야 한다.)
- test : test 코드의 작성 및 수정이 이루어졌을 때
- docs : README 등 문서 내용을 변경하였을 때
- chore : 외부 라이브러리 임포트 등의 작업을 완료했을 때
<subject>
- 첫 글자는 대문자로 작성, 마침표는 안 쓴다.
- 50자 이내로 작성
- 현재형, 명령문으로 작성
<body>
본문으로 헤더에서 생략한 상세한 내용을 작성합니다. 헤더로 충분한 표현이 가능하다면 생략이 가능합니다.
- 공백 라인으로 주제와 본문을 구분
- 각 줄을 72자로 제한
<footer>
바닥글로 어떤 이슈에서 왔는지와 같은 참조 정보를 추가하는 용도로 사용합니다.
이 밖에도 커밋 메시지 작성을 위해 참고하면 좋은 자료입니다.
Conventional Commits
A specification for adding human and machine readable meaning to commit messages
www.conventionalcommits.org
커밋 제목 지을 때 참고용
ull.im
울려 퍼지다.<br/> 반향하다.<br/> 공명하다.
blog.ull.im
좋은 커밋 메시지의 예
좋은 커밋 메시지를 생각하기 앞서 Git의 역사에 대해 짧게 살펴보겠습니다.
Git은 Linux 운영 체제 커널의 유명한 제작자인 리누스 토르발스가 Linux 오픈소스를 개발하면서 원활하게 버전 관리를 하기 위해 2005년 처음 개발하였습니다. 오늘날 Git은 세계에서 가장 널리 사용되는 버전 관리 시스템입니다.
좋은 커밋 메시지에 똑부러진 답은 없습니다. 하지만 수많은 오픈소스 개발자들이 버전 관리를 위한 좋은 커밋 메세지에 대해 끊임없이 고민해왔습니다.
깃의 버전 관리는 오픈소스에서 파생이 된 것이기 때문에, 커밋 메세지 또한 역사 깊은 오픈소스들을 참고해 보면 좋은 커밋 메시지를 작성할 수 있으리라 생각합니다.
유명한 몇 가지 오픈소스 커밋 내용을 살펴보겠습니다.
다음은 국내 몇몇 기업의 오픈소스 커밋 내용을 살펴보겠습니다.
커밋은 언제 하는 것이 좋을까
커밋의 단위는 개발자들마다 생각이 다를 것입니다. 저는 제 경험을 바탕으로 원칙을 세워봤습니다.
1. 하나의 액션 당 하나의 커밋
안드로이드에서 로그인 기능을 예로 들자면,
로그인 ui 제작, 서버 통신 연동, 로그인 api 연동, 로그인 Unit 테스트 코드 작성 등 액션 단위로 커밋을 합니다.
커밋 단위는 한 줄로 설명할 수 있는 정도의 양이 좋습니다.
2. 잘게 쪼개서 커밋
적절하게 잘게 쪼개서 커밋을 할 경우, 혹시 모를 경우에 롤백이 쉬워지고 커밋 메시지도 간결해지며 가독성이 좋아집니다.
3. 작은 기능이라도 커밋
작은 기능이라고 모아서 한 번에 커밋을 하지 않습니다. 여러 번에 나눠서 커밋을 해야 합니다.
한 커밋에 여러 액션이 들어가는 순간 해당 커밋은 복잡한 커밋이 됩니다.
좋은 커밋 방법에 대한 내 생각
여러 스타트업에 근무를 하면서 빠른 출시도 중요하지만 얼마나 변화에 유연하게 잘 설계해서 만드느냐도 정말 중요하다는 것을 느꼈습니다. 프로젝트를 장기적으로 성공시키려면 무엇보다도 '얼마나 유지 보수를 고려해 개발하는가?'가 가장 중요하다고 생각합니다. 처음에는 번거로울 수 있겠지만 초기에 시간이 걸리더라도 유지 보수를 위한 규칙들을 세우고 잘 정의하면 결국에는 모든 협업 개발자들의 생산성이 증가하게 됩니다.
장기적으로 좋은 커밋 메시지를 작성하는 것은 당신이 얼마나 협력자인지를 보여줍니다.
협업을 잘 하기 위해
좋은 커밋, 커밋 메시지 작성을 위해 함께 노력해 봅시다 :)
'Main' 카테고리의 다른 글
| [Android] Service를 활용한 Timer 개발 (0) | 2022.11.30 |
|---|---|
| MVP 앱 개발 (4) | 2022.11.06 |
| [Android] 앱 아키텍처 설계 (0) | 2022.11.03 |
| [Android] Sentry를 활용한 앱 에러 트래킹 및 모니터링 (0) | 2022.10.29 |
| [Android] 스트리밍 서비스 개발 기록 (0) | 2022.10.14 |
댓글