[Git] 커밋 메시지, 브랜치 네이밍, 브랜치 작업순서, 레파지토리 네이밍 Convention

Git Convention

1. Commit Message Convention

커밋 메시지 구조

type: subject (제목)

body (본문)

footer (꼬리말)

 

 

 

Type

Feat	새로운 기능 추가한 경우
Fix	버그를 수정한 경우
BREAKING CHANGE	큰 API 변경이 있는 경우
HOTFIX	치명적인 버그를 급하게 수정해야 하는 경우
Style	코드 포맷 변경, 세미 콜론 누락 등 코드 수정이 없는 경우
Design	CSS 등 사용자 UI 디자인을 변경한 경우
Refactor	프로덕션 코드 리팩토링
Comment	필요한 주석 추가 및 변경
Docs	문서를 수정한 경우
Test	테스트를 추가한 경우
Chore	빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우
Rename	파일 혹은 폴더명을 수정하거나 옮기는 작업을 한 경우
Remove	파일을 삭제하는 작업을 한 경우

 

Subject

• 제목은 영문 기준 50자 이내로 작성한다.
• 첫 글자는 대문자로 작성하며 끝에 마침표를 찍지 않는다.
• 영문으로 작성하는 경우 동사(원형)을 가장 앞에 명령어로 작성한다.
• 과거시제는 사용하지 않는다.
• 간결하고 요점적으로 즉, 개조식 구문으로 작성한다.

 

Body

• 본문은 한 줄 당 72자 이내로 작성한다.
• 전체 내용은 양과 상관없이 최대한 상세하게 작성한다.
• '어떻게' 보단 '무엇을', '왜' 변경했는지를 설명한다.

 

Footer

• 꼬리말은 선택적이며 이슈 트래커 ID를 작성한다.
• 여러 개의 이슈 번호를 적을 때는 쉼표로 구분한다.
• 이슈 트래커 유형은 다음과 같다.
  • Fixes : 이슈 수정중 (아직 해결되지 않은 경우)
  • Resolves : 이슈를 해결했을 때
  • Ref : 참고할 이슈가 있을 때
  • Related to : 해당 커밋에 관련된 이슈 번호 (아직 해결되지 않음)
    • ex) Fixes: #45 Related to: #34, #23

 

 

2. Branch Naming Convention

master branch	사용자에게 배포 가능한 상태를 관리하는 branch, 라이브 브랜치
release branch	이번 출시 버전을 준비하는 branch, 라이브 배포 전 QA 테스트 브랜치, 정해진 배포 일정 시 develop 머지
develop branch	다음 출시 버전을 개발하는 branch, 개발 브랜치
feature branch	기능을 개발하는 branch. 새로운 기능 개발 및 버그 수정이 필요할 때마다 develop branch에서 분기한다. feature name 예시) feature/yyyymmdd-닉네임-기능명
hotfix branch	출시 버전에서 발생한 버그를 수정하는 branch. 배포한 버전에서 긴급히 수정을 해야 하는 경우에 master branch에서 분기한다.

 

- 작업 순서 예시 (회사마다 다름)

    1. local/develop checkout → fetch & merge 또는 pull 최신 소스 받기
    2. 피쳐 브랜치 따기
        local/develop > New Branch … → feature/날짜-이름-기능 → Create
    3. 피쳐 브랜치에서 코딩
    4. 피쳐 커밋 → 푸시
    5. local/develop checkout (디벨롭 브랜치로 이동) → fetch & merge 또는 pull 최신 소스 받기
        → 피쳐를 merge → push (디벨롭 브랜치를 푸시)
    -- 개발 할때는 위에까지 진행
    6. local/release checkout (릴리즈 브랜치로 이동) → fetch & merge 또는 pull 최신 소스 받기
        → 디벨롭을 merge → push (릴리즈 브랜치를 푸시)
    -- QA 진행 할 때 여기까지 진행
    7. local/master checkout (마스터 브랜치로 이동) → fetch & merge 또는 pull 최신 소스 받기 
        → 릴리즈를 merge → push (마스터 브랜치를 푸시)
    -- 배포 할 때 여기까지 진행

 

3. Repository Naming Convention

• 소문자를 사용한다.
• 대시(-)를 사용한다.
• 명확하게 작성한다.
• 일관성 있게 작성한다.