Git : 좋은 커밋이 하고 싶다면 들어와! (feat. Google)

커비·2024년 11월 29일
구글 커밋 컨벤션커밋필독
0

Git

목록 보기
1/2

❓ 좋은 커밋이라니? 너도 초보잖아!

오늘은 Google Commit Messege Convention 에 대해 이야기를 해보려고 한다. 이전에 함께 프로젝트를 했던 팀원분이 공유해주셔서 알게되어 조금 더 자세하게 공부해보았다!

초보일수록 더욱 정확한 정보로 탄탄하게 자라야한다고 생각하기 때문에 ChatGPT 와 Google, GitHub의 힘을 빌려 정리한 내용을 공유해보려고 한다!

시작하기에 앞서 기본으로 알고 가야할 3가지가 있다!

  • 협업툴에서의 소통 중 하나이기에 협업자가 쉽게 이해할 수 있도록 구체적인 정보를 제공해야한다.
  • 변경 사항의 의도를 강조해서 남긴다.
  • 간결하고 명확하게 작성한다.

이 부분에 대해 기본옵션으로 인지하고 아래 내용을 습득하는 것이 좋다!

❓ Google Commit Messege Convention 그게 뭔데?

Google Commit Messege Convention은 일관되고 쉬운 커밋 기록을 유지하는데 중점을 두고 보통 AngularJS 커밋 스타일 가이드를 기반으로 한다!
(내가 봐도 설명 어려우니까 아래로 이동!)

🚨 커밋 스타일 가이드 예시

타입() : 간단한 내용(명령문 형태로 작성)
==== 한 줄 띄우고 ====
상세 내용
==== 한 줄 띄우고 ====
이슈 번호 또는 브레이킹 체인지에 대한 내용

우선, 첫번째 줄은 모두 필수로 입력해줘야하고 두번째줄과 세번째줄은 필요할 때만 입력하면 된다.

❓ 타입에는 뭘 적어야해?

타입은 변경 사항의 성격을 나타낼 수 있도록 입력해야하는데 주로 입력하는 용어는 아래와 같다.

🚨 타입(tupe)에 입력하는 주 용어

feat - 새로운 기능 추가
fix - 버그 수정
ci - CI 관련 수정에 대한 커밋 타입
docs - 문서 수정 (예: README 변경)
style - 코드 스타일 변경 (공백, 들여쓰기 수정 등)
refactor - 코드 리팩토링 (기능 변경 없음)
test - 테스트 추가 또는 수정
build - 빌드 관련 파일 수정에 대한 커밋 타입
chore - 빌드/배포 관련 작업, 패키지 관리 작업 등

❓ 타입 옆에 ( )에는 뭘 적어야해?

타입 옆에 있는 괄호에는 변경된 기능이나 모듈의 범위를 나타내는 곳이다.

🚨 모듈의 범위(scope)를 나타내는 용어

auth - 새로운 기능 추가
config - 설정이나 시스템 관련 기능 추가
ui or art - UX/UI 개선이나 디자인 추가
utils - 도구나 유틸리티 추가
app - 모바일 관련 기능 추가
api - API 관련 작업
db - 데이터베이스 또는 데이터 추가

❓ 간단한 내용 부분은 맘대로 적어도 돼?

맘대로 적기에는 컨벤션규칙이 있기 때문에 그럴 수 없고 아래를 참고하면 좋다.

🚨 간단한 내용(subject) 부분 작성방법

  • 첫 글자는 소문자로 시작한다. (영문)
  • 50자 이내로 작성한다
  • 마침표를 사용하지 않는다.

사실 나는 마침표를 사용하지 않는 점에서 조금 의아했고 적응하기 힘들었다! 하지만 정해진 규칙을 맘대로 어길 수 없으니 자연스럽게 따를 수 있도록 적응해야겠다.

❓ 선택사항인 상세 내용 부분도 제한되는 게 있을까?

선택사항인 만큼 없을 줄 알았는데 간단한 규칙이 있었다.

🚨 상세 내용(body) 작성방법

  • 무엇을, 왜 변경했는지에 대해 입력한다.
  • 줄의 길이는 72자를 넘지 않도록 작성한다.

❓ 마지막 줄은 하나도 모르겠어!

나도 처음엔 이슈 번호와 브레이킹 체인지 자체가 무엇인지 하나도 몰랐다. 그래서 알아보았다!

이슈번호나 브레이킹 체인지는 협업 환경에서 커밋의 의도와 변경 사항의 중요성을 명확하게 전달하기 위해 커밋 메시지에 추가하는 중요한 요소라고 한다.

이슈번호

버그, 기능 요청, 개선 사항 등을 관리하는 이슈 트래커(GitHub Issues, Jira)의 특정 항목을 가리키는 번호를 의미하고 이슈 번호를 포함하면 특정 이슈와 관련 있다는 것을 연결할 수 있다.

이슈번호 포함하는 이유

  1. 추적성
    어떤 코드 변경이 특정 요구사항이나 버그 수정을 위해 이루어졌는지 쉽게 파악 가능함
  2. 자동화
    GitHub 같은 도구에서는 Fixes #<번호> 또는 Closes #<번호> 를 작성하면 이슈를 자동으로 닫아줌

이슈번호 사용방법

  • 완료된 경우 : Fixes #123 또는 Closes #123
  • 참고용 : Refs #123 또는 Related to #123

브레이킹 체인지 (Breaking Change)

기존 기능이나 인터페이스를 변경해 이전 버전과 호환되지 않게 만드는 변경 사항을 의미함
브레이킹 체인지로 인해 기존 코드나 사용자에게 수정 작업이 요구됨

브레이킹 체인지를 포함하는 이유

  1. 팀이나 사용자에게 변경 내용을 미리 알림
  2. 코드 배포 시 주요 업데이트를 강조하여 의도하지 않은 문제를 방지

브레이킹 체인지 사용방법

  • BREAKING CHANGE: 키워드를 필수 사용
  • 무엇이 변경되었는지, 왜 변경되었는지 명확하게 설명

🚨 이슈번호와 브레이킹 체인지 사용 예시

feat(config): add support for environment variables

Implemented functionality to load configuration from .env files.
BREAKING CHANGE: The application now requires a .env file to run. Refer to the documentation for setup instructions.
Fixes #78

간단 정리!

이슈번호는 팀에서 관리 중인 특정한 이슈를 해결하는 커밋에 항상 포함하기!
브레이킹 체인지는 중요한 변경 사항이 있을 때만 추가하기! (ex. API 경로 변경, 함수 이름 변경, 설정 파일 구조 변경 등)

🥺 자, 작성방법은 알겠어. 근데 난 이모지도 쓰고싶은걸?

깃에 사용하는 이모지를 깃모지라고 부르곤 하는데 깃모지를 쓰기 전에 확인해야하는 부분들이 있다.

  • 팀에서 자주 사용하는 이모티콘 리스트 또는 정해진 이모티콘 리스트를 확인하여 일관성을 유지하는 것이 효과적이다.
  • 메시지의 가독성을 해치지 않도록 맨 앞 부분에 간결하게 사용하는 것이 좋다.
  • 너무 많은 아이콘은 혼란을 줄 수 있어서 상황에 맞게 1~2개까지가 적당하다.

feat(새로운 기능 추가) 커밋에 사용할 추천 이모티콘

🌟 - 새로운 기능의 추가를 강조할 때
✨ - 새로운 기능이나 개선된 기능 추가
🆕 - 새로운 것을 도입할 때
💡 - 기능 아이디어를 구현할 때
🚀 - 주요 기능 출시나 초기 단계 구현
🛠️ - 새로운 기능을 위한 준비 작업

일반적인 기능 추가를 나타내는 이모티콘

✨ - 새로운 기능이나 개선 사항 추가

✨ feat(module-name): add step 1 functionality

특정 상황에 따른 추천 이모티콘

1. 기능 관련
🆕 - 새로운 기능 추가

🆕 feat(auth): add user authentication feature

⚙️ - 설정이나 시스템 관련 기능 추가

⚙️ feat(config): add support for environment variables


2. UI/UX 관련
🎨 - UI/UX 개선이나 디자인 추가

🎨 feat(ui): implement new button styles


3. 특정 기술 스택
🔧 - 도구나 유틸리티 추가

🔧 feat(utils): add a helper function for API calls

📱 - 모바일 관련 기능 추가

📱 feat(app): implement swipe gesture handling


4. API 관련
🌐 - API 관련 작업

🌐 feat(api): add endpoint for user profiles


5. 데이터 관련
🗃 - 데이터베이스 또는 데이터 추가

🗃 feat(db): add migration for user table

좋은 커밋 방법 예시

좋은 커밋 방법에 대해 예시를 가져오는 편이 좋을 것 같아서 몇가지 적어본다.

새 기능이 추가되어 커밋할 때

<feat(module-name): implement step 1 functionality

Added the initial logic for step 1. This includes basic validation and API setup.
Further enhancements will follow in subsequent commits.

Fixes #123

어디서 본 커밋 같다면 빙고! 내가 개인과제 : 키오스크 를 커밋할 때 사용한 문장들이다.

리팩토링할 때

<refactor(module-name): improve step 1 code structure

Refactored the logic to improve readability and maintainability. No functionality changes.

위에서 이야기한 것처럼 간단한 내용 부분은 소문자로 시작하고

테스트 추가할 때

<test(module-name): add unit tests for step 1 functionality

Added unit tests to cover the main scenarios for the new feature implemented in step 1.

Git Commit은 스스로 겁먹어서 어렵게 느낀 것일 수도 있다 !

profile
커비
전공은 컴퓨터공학, 복수전공은 해킹보안학, 직장은 방학(파워 구직중)
다음 포스트

Git : Git 기초

2개의 댓글

comment-user-thumbnail
박재성
2024년 11월 29일

멋지십니다. 응원할게요!

1개의 답글