17. 브랜치 규칙

브랜치 네이밍 규칙을 설정하는 것은 프로젝트 관리와 팀 협업을 효율적으로 진행하기 위해 중요합니다. 아래는 일반적으로 사용되는 브랜치 네이밍 규칙입니다. 이 규칙을 통해 브랜치의 목적과 내용을 명확히 하고, 프로젝트의 가독성을 높일 수 있습니다.

1. 메인 브랜치

• main 또는 master: 프로젝트의 안정적인 배포 버전을 유지하는 브랜치입니다. 모든 최종 버전의 코드가 여기에 머물러야 하며, 직접적으로 커밋하지 않는 것이 좋습니다. 대신 Pull Request(PR)를 통해 검토된 코드만 병합합니다.

2. 개발 브랜치

• develop: 새로운 기능 개발, 버그 수정 등이 이루어지는 브랜치입니다. 모든 기능 브랜치가 병합되는 곳이며, 이 브랜치에서 안정화된 코드는 main 브랜치로 병합됩니다.

3. 기능 브랜치 (Feature Branch)

• feat/{브랜치 이름}: 새로운 기능을 개발하는 브랜치입니다. 기능이 완료되면 develop 브랜치로 병합됩니다.
• 예시: feat/rocksdb-log-storage, feat/implement-new-ui

4. 버그 수정 브랜치 (Bugfix Branch)

• bugfix/{브랜치 이름}: 버그를 수정하는 브랜치입니다. 수정이 완료되면 develop 또는 main 브랜치로 병합됩니다.
• 예시: bugfix/fix-login-error, bugfix/correct-missing-dependencies

5. 핫픽스 브랜치 (Hotfix Branch)

• hotfix/{브랜치 이름}: 긴급한 버그 수정을 위해 사용하는 브랜치입니다. 주로 main 브랜치에서 발생한 이슈를 긴급하게 수정할 때 사용하며, 수정 후 main과 develop 브랜치에 병합됩니다.
• 예시: hotfix/security-patch-v1.0.1, hotfix/fix-critical-bug

6. 릴리즈 브랜치 (Release Branch)

• release/{버전}: 새로운 배포 버전을 준비하기 위해 사용하는 브랜치입니다. 배포 전 마지막으로 테스트하고, 배포 준비가 완료되면 main 브랜치로 병합합니다. 이후 develop 브랜치에도 병합하여 다음 개발 사이클에 반영합니다.
• 예시: release/v1.0.0, release/v2.1.0

7. 실험 브랜치 (Experimental Branch)

• experiment/{브랜치 이름}: 새로운 아이디어나 실험적인 기능을 테스트하기 위해 사용하는 브랜치입니다. 안정성이 보장되지 않은 코드를 포함할 수 있으며, 성공적일 경우 기능 브랜치로 전환할 수 있습니다.
• 예시: experiment/try-new-cache-implementation, experiment/alternative-logging

8. 문서화 브랜치 (Documentation Branch)

• docs/{브랜치 이름}: 문서화 작업을 위한 브랜치입니다. 주로 프로젝트의 README, API 문서, 기타 개발 관련 문서를 수정할 때 사용됩니다.
• 예시: docs/update-api-docs, docs/improve-readme

9. 리팩토링 브랜치 (Refactor Branch)

• refactor/{브랜치 이름}: 코드 리팩토링 작업을 위해 사용하는 브랜치입니다. 기능 변경 없이 코드 구조를 개선하는 작업을 포함합니다.
• 예시: refactor/clean-up-auth-module, refactor/optimize-database-queries

10. 테스트 브랜치 (Test Branch)

• test/{브랜치 이름}: 테스트 코드 작성 및 테스트 환경 설정을 위한 브랜치입니다.
• 예시: test/add-unit-tests, test/integrate-ci

11. 작업 번호 포함 규칙 (Optional)

• 이슈 트래커와 연동하여 작업 번호를 포함할 수 있습니다. 예를 들어 GitHub Issues 또는 Jira 등의 도구와 함께 사용되는 경우, 이슈 번호를 브랜치 이름에 포함하여 추적을 용이하게 할 수 있습니다.
• 예시: feat/rocksdb-log-storage-#93, bugfix/fix-typo-#102

12. 네이밍 규칙 예시

• 기능 추가: feat/add-user-authentication
• 버그 수정: bugfix/resolve-login-issue
• 긴급 수정: hotfix/fix-payment-gateway-error
• 배포 준비: release/v2.0.0
• 실험 기능: experiment/new-caching-strategy
• 문서 수정: docs/update-contribution-guide
• 리팩토링: refactor/improve-error-handling

이러한 규칙을 팀 전체에서 일관되게 사용하면, 브랜치 이름만으로도 작업의 목적과 내용을 쉽게 파악할 수 있어 협업이 훨씬 수월해집니다.