Git을 사용할 때 규칙(Convention)을 사용하면 여러 사람들과 협업할 때, 보다 효율적으로 일할 수 있다.
본 글에서는 commit message convention, branch naming convention, repository naming convention에 대해 알아본다.
1. Commit Message Convention
먼저 commit message의 구조는 위 사진과 같다.
맨 위부터 제목, 본문, 꼬리말로 구성되어있다.
1.1. type
내가 작성한 commit message의 의도를 다른 사람들에게 전달하기 위해선 위 구조에서 <type> 부분에 다음과 같은 요소들을 포함한다.
| fix | 버그를 수정한 경우 |
| feat | 새로운 기능을 추가한 경우 |
| BREAKING CHANGE | 큰 API 변경이 있는 경우 |
| HOTFIX | 치명적인 버그를 급하게 수정해야 하는 경우 |
| Style | 코드 포맷 변경, 세미 콜론 누락 등 코드 수정이 없는 경우 |
| Refactor | 프로덕션 코드 리팩토링 |
| Comment | 필요한 주석 추가 및 변경 |
| Docs | 문서를 수정한 경우 |
| Test | 테스트를 추가한 경우 |
| Chore | 빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우 |
| Rename | 파일 혹은 폴더명을 수정하거나 옮기는 작업을 한 경우 |
| Remove | 파일을 삭제하는 작업을 한 경우 |
1.2. subject
- 제목은 영문 기준 50자 이내로 작성한다.
- 첫 글자는 대문자로 작성하며 끝에 마침표를 찍지 않는다.
1.3. Body
- 본문은 한 줄 당 72자 이내로 작성한다.
- 전체 내용은 양과 상관없이 최대한 상세하게 작성한다.
- '어떻게' 보단 '무엇을', '왜' 변경했는지를 설명한다.
1.4. footer
- 꼬리말은 선택적이며 이슈 트래커 ID를 작성한다.
- 여러 개의 이슈 번호를 적을 때는 쉼표로 구분한다.
- 이슈 트래커 유형은 다음과 같다.
- Fixes : 이슈 수정중
- Resolves : 이슈를 해결했을 때
- Ref : 참고할 이슈가 있을 때
- Related to : 해당 커밋에 관련된 이슈 번호(아직 해결되지 않음)
- ex) Fixes: #45 Related to: #34, #23
2. Branch Naming Convention
| master branch | 사용자에게 배포 가능한 상태를 관리하는 branch. |
| develop branch | 다음 출시 버전을 개발하는 branch. 배포가 가능해진 상태가 되면 develop branch를 master branch로 merge한다. |
| feature branch | 기능을 개발하는 branch. 새로운 기능 개발 및 버그 수정이 필요할 때마다 develop branch에서 분기한다. |
| release branch | 이번 출시 버전을 준비하는 branch. |
| hotfix branch | 출시 버전에서 발생한 버그를 수정하는 branch. 배포한 버전에서 긴급히 수정을 해야 하는 경우에 master branch에서 분기한다. |
3. Repository Naming Convention
- 소문자를 사용한다.
- 대시(-)를 사용한다.
- 명확하게 작성한다.
- 일관성 있게 작성한다.
https://velog.io/@kim-jaemin420/Git-branch-naming, https://stackoverflow.com/questions/11947587/is-there-a-naming-convention-for-git-repositories
를 참고하여 작성하였습니다.
'git' 카테고리의 다른 글
| [git] branch conflict 해결하기 (0) | 2022.01.11 |
|---|---|
| [git] 새로운 branch에 새로운 Xcode 프로젝트 push 하기 (feat. mac, 깃허브, iTerm, pull request) (0) | 2022.01.07 |
