3.3. 버전 관리

브랜치 전략 (Git branch strategy)

• main - 운영
• dev - 개발
• feature - 기능 추가
  • ex) feature/#{이슈번호}
• hotfix - 버그 수정
  • ex) hotfix/#{이슈번호}

---

커밋 메시지 컨벤션 (Git commit convention)

참고 : Angular JS commit convention

[커밋 메시지 헤더]
<type>: <short summary>
  │              │
  │              └─⫸ 현재 시제로 작성한다. 마침표로 끝내지 않는다. 동사보단 명사 형태.
  │ 
  └─⫸ Commit Type: build|docs|feat|fix|refactor|test|style

• feat : 새로운 기능 추가
• fix : 버그 수정
• docs : 문서 관련 (gitignore, README, 각종 템플릿 등)
• style : 스타일 변경 (포매팅 수정, 들여쓰기 추가, …)
• refactor : 코드 리팩토링
• test : 테스트 관련 코드
• build : 최초 프로젝트 설정, 빌드 관련 파일 수정(build gradle 의존성 추가, yml 파일 생성 등)
• chore : 패키지 구조 변경, 삭제, 기타 작업들

---

브랜치 보호 규칙 (Branch protection rule)

• main 브랜치

  1. Require a pull request before merging
     • merge를 위해 pull request를 강제하는 옵션
     • approvals 3명일 때만 merge 가능하도록 설정
  2. Require status checks to pass before merging
     • merge 전에 테스트 코드등을 돌려 상태를 무조건 먼저 체크하는 옵션
  3. Require linear history
     • merge할 때, squash-merge나 rebase-merge만을 허용하는 옵션
     • 별도의 머지 커밋이 생기지 않도록 방지
  4. Lock branch
     • 누구도 브랜치에 푸시할 수 없도록 read-only로 만듦
  5. Do not allow bypassing the above settings
     • 관리자 권한을 가진 유저들도 해당 설정을 지키지 않으면 머지할 수 없도록 막음

• dev 브랜치 (기본 브랜치)

  1. Require a pull request before merging
     • merge를 위해 pull request를 강제하는 옵션
     • approvals 1명 이상일 때만 merge 가능하도록 설정
  2. Require status checks to pass before merging
     • merge 전에 테스트 코드등을 돌려 상태를 무조건 먼저 체크하는 옵션
  3. Require linear history
     • merge할 때, squash-merge나 rebase-merge만을 허용하는 옵션
     • 별도의 머지 커밋이 생기지 않도록 방지
  4. Lock branch
     • 누구도 브랜치에 푸시할 수 없도록 read-only로 만듦
  5. Do not allow bypassing the above settings
     • 관리자 권한을 가진 유저들도 해당 설정을 지키지 않으면 merge할 수 없도록 막음