Git Commit Convention

코드 정리에 앞서...

개발자가 아닌 PM으로 프로젝트에 참여해왔으나, 다양한 배경이야기 속에서 데이터 분석을 하고 있다. 우리 팀이 그 동안 잘 써왔던 커밋 컨벤션을 공유하고 정리해봐야겠다.

아래는 우리 팀에서 든든한 백이 되어 주었던 지구님이 작성한 컨벤션 문서이다.

PI_Dev team convention

Branching

DEV 팀은 Lightweight Branching Model 에 착안하여 협업 및 배포 프로세스를 만들어나갈 예정입니다.

Feature Branch: 새로운 기능을 추가하는 경우, feat/[기능이름] 의 형태로 develop 브랜치에서 분기합니다. 기능의 이름은 조금 길더라도 세부적으로 적습니다. 기능을 추가하는 행위와 추가한 기능을 고치는 행위 모두 feature 브랜치에서 일어나기 때문에 브랜치 이름에서 작업의 스코프를 짐작할 수 있도록 합니다.
Develop Branch: feature 브랜치에서 작업한 후 테스팅을 거친 뒤, develop 브랜치로 PR 을 날립니다. 빌드에 실패하거나, 테스트를 거치지 않은 경우 PR 을 닫아주세요.
Master Branch: master 브랜치로 push 할 정도로 검증이 된 코드만 master 브랜치로 push 합니다. Master 브랜치로의 PR 과 merge 는 대면 정기 미팅에서 충분한 검토를 거친 뒤, 수행하도록 합니다.

Commit Message Rules

아래와 같은 카테고리로 커밋 메시지를 남기도록 합니다.

feat: 기능 추가인 경우
fix: 기존 코드를 수정하는 경우
design: UI만 수정하는 경우
refac: 기존 코드를 (기능변경 없이) 리팩토링하는 경우
test: 테스크 코드를 추가하는 경우
style: 공란, 빈 줄 제거 등 단순히 코드가 보여지는 방식만 수정하는 경우
comment: 주석만 변경/추가/제거한 경우

PR & Merge

merge 된 모든 feature 브랜치는 remote 에서 삭제합니다.
PR 을 생성할 때에는 본인을 담당자로 지정합니다. 또한 업무와 관련있는 사람을 리뷰어로 등록합니다. 리뷰어는 최소 한명을 지정하도록 합니다.
리뷰어로 지정을 받은 사람은 12시간 안에 코멘트를 남기도록 합니다.
본인이 생성한 PR 에 대해서는 본인이 머지를 수행하도록 합니다.
PR 의 단위는 light 하게 설계합니다.
Feature 브랜치에서 Develop 브랜치로의 merge 는 squash and merge 로 진행합니다.
Develop 브랜치에서 Master 브랜치로의 merge 는 rebase and merge 로 진행합니다. (별도 커밋 생성 필요없음)

Testing

Github Action 을 사용하여 PR 생성 시 빌드 및 테스트를 진행합니다. 이 테스트를 통과한 PR 만을 merge 합니다.

Deployment

배포의 경우, 프로젝트의 특징에 맞게 프로젝트 초기 단계에 논의하여 정하도록 합니다.

---

우리의 convention을 만들 때는, 뱅크 샐러드나 다른 기업들의 개발 문화를 최대한 우리 팀의 특성에 맞게 수정하는데 주안점을 두었었다.
팀이라고는 하지만
1. 각자 개발을 하는 서비스가 제각각이었고,
2. 팀도 프로젝트에 따라서 참여하는 인원이 달라서 많은 부분에서 여지를 남겨두고,
3. 프로젝트에 마다 자율성을 많이 보장하는 방안을 궁구했다.
조금 어려움이 있지만, 우리 팀에 대해서 기회가 된다면 소개할 일이 생기면 좋겠다는 마음이 있다.

아래 부터는 내가 사용하기 위해서 좀 더 디테일하게 작성하고 다른 글들을 보고 추가하였다.

comment의 기본 구조

1. type: subject

• 제목은 한눈에 볼수 있게(검색 시) 2줄 이내 50자 내로 적는다*
• type과 함께 emoji를 써서 구분을 쉽게 한다*
• JIRA를 잘 활용하고 있다면 서두에 JIRA 티켓 넘버를 써야한다*
• 타블로그 등에서 지시문/ 명령문/ 동사원형으로 써야한다는 말이 있는데 이는 글로벌하게 영어를 번역하면서 생긴 것이고(이해는 잘 되지만), 정확하게는 '완결된 사항에 대한 기능(동작)'을 작성한다고 보는게 맞지않을지
• 2칸을 띄워줘야 구분이 용이하다*

2. body

• 상세한 내용을 적는데, 간략하고 정확하게 개조식으로 작성한다*
• 개발의 목적 혹은 원인, 신규 혹은 변경 내용을 적는다
• 300자 이내로..

3. footer

• metadata의 작성
• 이전 버전과 연결되는 지점이나, 개발자가 검토가 필요한 내용 등을 적는다*

type의 기술 방법

• 보면 알겠지만, emoji가 상당히 많다. 하지만 그만큼 간단하고 도움이 된다. 우리 조직에서 어떤 이모지를 쓰는지 알아두면 훨씬 편할 것이다.

Tag Name	Description
Feat	새로운 기능을 추가
Fix	버그 수정
Design	CSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE	커다란 API 변경의 경우
!HOTFIX	급하게 치명적인 버그를 고쳐야하는 경우
Style	코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor	프로덕션 코드 리팩토링
Comment	필요한 주석 추가 및 변경
Docs	문서 수정
Test	테스트 코드, 리펙토링 테스트 코드 추가, Production Code(실제로 사용하는 코드) 변경 없음
Chore	빌드 업무 수정, 패키지 매니저 수정, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음
Rename	파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove	파일을 삭제하는 작업만 수행한 경우\

Emoji의 사용 방법

Emoji	Description
🎨	코드의 형식 / 구조를 개선 할 때
📰	새 파일을 만들 때
📝	사소한 코드 또는 언어를 변경할 때
🐎	성능을 향상시킬 때
📚	문서를 쓸 때
🐛	버그 reporting할 때, @FIXME 주석 태그 삽입
🚑	버그를 고칠 때
🐧	리눅스에서 무언가를 고칠 때
🍎	Mac OS에서 무언가를 고칠 때
🏁	Windows에서 무언가를 고칠 때
🔥	코드 또는 파일 제거할 때 , @CHANGED주석 태그와 함께
🚜	파일 구조를 변경할 때 . 🎨과 함께 사용
🔨	코드를 리팩토링 할 때
☔️	테스트를 추가 할 때
🔬	코드 범위를 추가 할 때
💚	CI 빌드를 고칠 때
🔒	보안을 다룰 때
⬆️	종속성을 업그레이드 할 때
⬇️	종속성을 다운 그레이드 할 때
⏩	이전 버전 / 지점에서 기능을 전달할 때
⏪	최신 버전 / 지점에서 기능을 백 포트 할 때
👕	linter / strict / deprecation 경고를 제거 할 때
💄	UI / style 개선시
♿️	접근성을 향상시킬 때
🚧	WIP (진행중인 작업)에 커밋, @REVIEW주석 태그와 함께 사용
💎	New Release
🔖	버전 태그
🎉	Initial Commit
🔈	로깅을 추가 할 때
🔇	로깅을 줄일 때
✨	새로운 기능을 소개 할 때
⚡️	도입 할 때 이전 버전과 호환되지 않는 특징, @CHANGED주석 태그 사용
💡	새로운 아이디어, @IDEA주석 태그
🚀	배포 / 개발 작업 과 관련된 모든 것
🐘	PostgreSQL 데이터베이스 별 (마이그레이션, 스크립트, 확장 등)
🐬	MySQL 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)
🍃	MongoDB 데이터베이스 특정 (마이그레이션, 스크립트, 확장 등)
🏦	일반 데이터베이스 별 (마이그레이션, 스크립트, 확장명 등)
🐳	도커 구성
🤝	파일을 병합 할 때