서론
저는 개발 및 공부 중에 Git을 항상 사용해왔습니다. 특히 협업 프로젝트에서 Git의 강력한 형상관리 기능 덕분에 큰 도움을 받았는데요, 협업 중 발생하는 수많은 커밋 로그를 보면서 문득 '좀 더 규칙적인 커밋 메시지를 작성하면 좋겠다'는 생각이 들었습니다. 그래서 찾게 된 것이 바로 AngularJS Git Commit Message Conventions 입니다. 이번 포스팅에서는 제가 공부한 내용을 정리하고, 이 컨벤션을 기반으로 Changelog.md 파일을 생성하는 방법을 공유하려 합니다.😎
1. AngularJS Git Commit Message Conventions란?
AngularJS Commit Message Conventions는 구글의 AngularJS 프로젝트에서 시작된, 명확하고 일관성 있는 커밋 메시지를 작성하기 위한 규칙입니다. 이 규칙은 코드 변경 내역을 보다 쉽게 추적하고 관리하기 위해 고안되었습니다. Angular 팀이 이 규칙을 도입한 이유는 자동화된 릴리즈 관리 도구와 통합할 수 있는 구조적인 커밋 메시지 체계를 구축하기 위해서였습니다. 이를 통해, 커밋 메시지를 바탕으로 자동으로 릴리즈 노트를 생성하고, 버전 관리를 일관되게 수행할 수 있었습니다.
시작 배경:
AngularJS는 많은 개발자가 참여하는 오픈소스 프로젝트였기 때문에, 커밋 메시지의 일관성은 협업에 있어 중요한 부분이었습니다. 각각의 커밋 메시지가 명확한 형식과 의미를 갖도록 하고, 이를 바탕으로 체계적인 릴리즈 관리와 버전 번호 증분을 쉽게 하기 위해 이 Commit Message Conventions를 도입한 것입니다.
이 방식은 이후 Conventional Commits라는 표준화된 방식으로 발전했고, 지금은 많은 오픈 소스 프로젝트에서 이 방식을 따르고 있습니다. Conventional Commits는 주로 semantic-release와 같은 자동화된 릴리즈 도구와 함께 사용되며, 릴리즈 자동화와 버전 관리의 표준으로 자리 잡았습니다.
커밋 메시지 규칙
AngularJS 커밋 메시지는 기능 추가, 버그 수정, 문서 변경 등 커밋의 목적을 명확히 하기 위해 특별한 형식을 따릅니다. 주요 규칙은 다음과 같습니다.
<커밋 메시지 구조>
커밋 메시지는 다음과 같은 구조를 따릅니다:
<타입>(<범위>): <주제>
<본문>
<꼬리말>
<type>(<scope>): <subject>
<body>
<footer>
이러한 커밋 메시지 구조는 3가지로 분류됩니다.
1) <type>(<scope>): <subject> — 헤더
헤더는 커밋 메시지의 가장 중요한 부분으로, 커밋의 요약을 담고 있습니다.
-
<type>:- 변경 사항의 유형을 나타냅니다. 주로 사용되는 유형은 다음과 같습니다.
feat: 새로운 기능 추가fix: 버그 수정docs: 문서 수정 (코드가 아닌 문서 파일의 변경)style: 코드 포맷팅, 공백, 세미콜론 수정 등 (기능 변화 없음)refactor: 코드 리팩토링 (기능 변화 없음)test: 테스트 코드 추가 또는 수정chore: 빌드 또는 기타 설정 파일 수정 (코드 변화 없음)
-
<scope>:
범위는 커밋 변경의 위치를 지정하는 것이면 무엇이든 될 수 있습니다. 예를 들어 $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView 등... -
<subject>:- 변경 사항을 간단하고 명확하게 요약한 한 줄 메시지입니다.
- 명령어와 현재형을 사용합니다.
“change”이지 “changed”도 아니고 “changes”도 아닙니다. - 문장의 끝에는 마침표를 찍지 않습니다.
예시:
feat(login): add login functionality
fix(api): resolve authentication issue2) <body> — 본문
본문은 커밋에 대한 더 자세한 설명을 적는 부분으로, 변경된 이유나 추가적인 정보를 담을 수 있습니다. 각 줄은 72자 내로 작성하는 것이 좋으며, 필요한 경우 이 부분에 이슈 번호를 언급할 수 있습니다.
- 목적: 커밋에서 수행된 작업의 이유나 세부 설명을 포함합니다.
- 포맷: 깔끔하고 명확하게 작성해야 합니다. 본문은 필수가 아니며, 커밋의 복잡성에 따라 생략할 수 있습니다.
예시:
feat(api): implement user registration
This commit adds a new user registration feature to the API.
Validation for the input fields and proper error handling is included.
The registration endpoint follows REST conventions.3) <footer> — 푸터
푸터는 커밋과 관련된 추가적인 정보나 메타데이터를 기록하는 부분입니다. 주로 다음과 같은 내용이 들어갑니다:
- Breaking Changes: 기능에 큰 변경이 있어 하위 호환성이 깨지는 경우 이를 명시합니다. 변경된 내용과 그로 인해 생기는 영향을 설명합니다.
BREAKING CHANGE: The login API now requires OAuth tokens instead of passwords.
- 🛑Issue Tracker Reference: 해결한 이슈 번호를 언급할 수 있습니다.
Closes #123
🔻여기서 Issue란??
git에서 Issue란 프로젝트 관리 및 버그 추적을 위한 도구로 프로젝트 시에 이슈 기능을 통해 팀원들이 프로젝트의 문제점, 요청사항, 버그, 개선점 등을 기록하고 관리할 수 있습니다. 따로 설정할수 있습니다.
Iusse 만들기
- 자신의 git 리포지토리로 들어가면 Issues가 있습니다. 이후 New Issue를 눌러줍니다
-
이후 Issue 제목과 내용을 적고
Submit을 해줍니다
-
생성된 이슈에는 #3이 붙었고 코멘트까지 추가할 수 있습니다.
Changelog.md 생성해보기
Changelog.md를 생성해보겠습니다.
1. 우선 이제까지 보낸 커밋을 확인해보겠습니다.
git bash 를 열어 명렁어를 입력합니다. 그렇다면 위에서 부터 최근에 커밋한 내용들이 출력됩니다.
git log<결과>
2. 커밋한 내역들을 확인해 보았으니 이제 Changelog.md를 생성해보겠습니다. 현재 로컬 저장소에는에는 Changelog.md 파일이 없습니다.
git bash를 열고 명령어를 입력해줍니다. 그러면 이렇게 Changelog.md파일이 생성된걸 볼 수 있습니다.
만약 이미 Changelog.md 파일이 있다면? 기존 파일 위에 새로운 파일을 덮어씌우게 됩니다.
git log --pretty="- %s" > CHANGELOG.md ⭕구성 요소 해석
git log
- Git 저장소의 커밋 이력을 보여주는 명령어입니다. 이 명령어를 사용하면 커밋 메시지, 날짜, 작성자 등의 정보를 확인할 수 있습니다.
--pretty="- %s"
- --pretty 옵션은 출력 형식을 지정합니다.
- "%s"는 커밋 메시지의 첫 줄(주제)를 의미합니다.
- "- %s"는 각 커밋 메시지를 대시(-)와 함께 출력합니다.
>
- 명령어의 출력을 지정한 파일로 보내는 역할을 합니다.
CHANGELOG.md
명령어의 출력 결과를 저장할 파일 이름입니다. 이 경우, CHANGELOG.md라는 파일이 생성되거나 기존 파일에 덮어쓰게 됩니다.
🔳이제 저의 로컬 저장소에 Changelog.md 파일이 생긴것을 알 수 있습니다.
<생성된 Changelog.md>
위쪽부터 최근의 커밋한 제목순서대로 md파일에 기록되는것을 확인할 수 있습니다.
후기
이번에 AngularJS Git Commit Message Conventions를 공부하고, 이를 바탕으로 CHANGELOG.md 파일을 생성해보았습니다. 처음 접하는 내용이라 생소하고 이해하기 어려웠지만, 앞으로 Git에 커밋할 때 이 규칙을 지키도록 노력할 계획입니다. 😉
향후 계획
사실, 커밋 시 자동으로 CHANGELOG.md 파일에 덮어쓰는 방법도 발견했습니다. 이는 추후에 다시 한 번 공부하여 적용할 계획입니다.
이 과정을 통해 커밋 메시지 작성의 중요성을 깊이 이해하게 되었고, 앞으로는 더 나은 프로젝트 관리에 기여할 수 있을 것 같습니다. 감사합니다! 👍
