[Git] 내가 보려고 만든 Git-flow기반 브랜치 전략 및 컨벤션

Git-flow기반 브랜치 전략 및 컨벤션

브랜치 컨벤션

1. Master Branch (master)

• 역할: 실제 제품으로 출시되는 안정된 버전이 배포되는 브랜치.
•  규칙
  • master 브랜치에 직접 커밋을 하지 않습니다.규칙:
  • 오직 release 브랜치 또는 hotfix 브랜치를 병합(Merge)할 때만 업데이트됩니다.
• 병합 대상: release, hotfix

---

2. Develop Branch (develop)

• 역할: 다음 출시 버전을 개발하는 메인 개발 브랜치.
• 규칙
  • 기능 개발이 완료된 후, feature 브랜치가 develop에 병합됩니다.
  • develop에서 release 브랜치가 생성됩니다.
• 병합 대상: feature, release

---

3. Feature Branch (feature/feature-name)

• 역할: 새로운 기능을 개발하는 브랜치.
• 규칙:
  • 새로운 기능을 개발할 때마다 feature/feature-name 형식으로 브랜치를 생성합니다.
  • 기능 개발이 완료되면, develop 브랜치로 병합합니다.
• 이름 규칙: feature/기능명 (예: feature/login-page)
• 병합 대상: develop

---

4. Release Branch (release/release-version)

• 역할: 이번 출시 버전을 준비하는 브랜치.
• 규칙:
  • 출시 직전, develop 브랜치에서 release/release-version 브랜치를 생성합니다.
  • 버그 수정이나 작은 수정만 가능하며, 새로운 기능은 추가하지 않습니다.
  • 준비가 완료되면 master로 병합하고, develop에도 병합하여 다음 버전 개발을 계속합니다.
• 이름 규칙: release/버전번호 (예: release/1.0.0)
• 병합 대상: master, develop

---

5. Hotfix Branch (hotfix/hotfix-name)

• 역할: 출시된 버전에서 발생한 버그를 긴급 수정하는 브랜치.
• 규칙:
  • 긴급한 버그 수정을 위해 master 브랜치에서 직접 hotfix/hotfix-name 브랜치를 생성합니다.
  • 버그 수정이 완료되면 master와 develop에 병합합니다.
• 이름 규칙: hotfix/버그명 
• (예: hotfix/login-bug, hotfix/critical-login-bug, fix/issue-101-login-bug)
• 병합 대상: master, develop

---

요약

• master: 출시된 안정된 코드만 존재 (최종 제품 버전).
• develop: 다음 버전을 개발하는 메인 브랜치.
• feature/기능명: 새로운 기능 개발.
• release/버전번호: 출시 준비.
• hotfix/버그명: 출시 버전에서 발견된 버그 긴급 수정.

---

커밋 메시지 컨벤션

커밋 메시지 구조:

[타입] 짧은 설명 (변경 사항)
(선택) 상세 설명

 

예시 : 

[feat] 회원가입 기능 추가
회원가입 API와 프론트엔드 연동 완료

 

타입 예시 : 

• feat: 새로운 기능 추가 
• fix: 버그 수정 
• docs: 문서 수정 
• style: 코드 포맷팅, 세미콜론 누락 등 기능과 상관없는 변경 사항 
• refactor: 코드 리팩토링 (기능 변경 없음) 
• test: 테스트 코드 추가/수정 
• chore: 빌드 업무 수정, 패키지 매니저 설정 등

---

커밋 메시지 규칙

• 간결하고 명확하게: 한 줄 요약(50자 이내)을 목표로 작성합니다.
• 영어 또는 한국어로 일관성 있게 작성합니다.
• 현재 시제 사용: "추가" 대신 "추가함" 또는 "Add" 대신 "Added"와 같은 표현을 사용하지 않습니다. 예시: feat: add login page (O), feat: added login page (X)
• 변경 목적을 명확히: 왜 이 변경이 필요한지, 무엇을 변경했는지를 간결하게 설명합니다.
• 같은 기능을 개발하는 초기 작업은 보통 기능 추가로 간주됩니다. 이 경우 커밋 메시지에는 새로운 기능 추가를 나타내는 feat 타입을 사용합니다.

---

푸시(Push) 규칙

작업 단위가 끝났을 때 푸시:

• 작은 단위의 기능이나 변경 사항이 완성되었을 때 푸시합니다. (너무 큰 단위로 한 번에 푸시하지 않도록 주의합니다.)

기능별/버그 수정별로 푸시:

• 하나의 브랜치에서 여러 기능을 작업 중일 때는, 각각의 기능이나 수정 사항이 완성될 때마다 따로 커밋하고 푸시합니다.
• 미리 Pull: 팀원들과의 충돌을 방지하기 위해 푸시 전에 항상 최신 코드를 pull하여 병합 충돌을 해결한 후 푸시합니다.

---

PR(Pull Request) 규칙

명확한 제목 작성:

• PR 제목에 어떤 기능이나 수정 사항인지 명확히 표시합니다.

설명 추가:

• PR 설명에 변경 사항, 테스트 방법, 참조 이슈 등을 명시합니다.

리뷰어 할당:

• 코드 리뷰를 받을 팀원을 할당하여 협업을 원활하게 진행합니다.