Git 브랜치 전략 및 협업 워크플로우 가이드

Git 브랜치 전략 및 협업 워크플로우 가이드

이 문서는 개발 팀의 효율적인 Git 사용을 위한 브랜치 전략과 협업 워크플로우에 대해 설명합니다. 이는 코드 통합 과정에서의 충돌을 최소화하고, 안정적인 릴리스 관리를 지원하며, 팀원 간의 원활한 협업을 돕는 것을 목표로 합니다.

1. 주요 브랜치 개념

• main (또는 master): 항상 배포 가능한 안정적인 코드를 유지하는 메인 브랜치입니다. 프로덕션 환경에 배포될 코드가 여기에 위치합니다.
• develop: 다음 릴리스를 위한 기능 개발이 통합되는 브랜치입니다. 개발 중인 기능들이 모이는 곳이며, main 브랜치보다 최신 상태를 유지합니다.
• feature 브랜치: 새로운 기능 개발을 위해 develop 브랜치에서 파생되는 임시 브랜치입니다. 개발이 완료되면 develop 브랜치로 병합됩니다. feature/<기능명> 또는 feat/<기능명> 형태로 명명하는 것이 일반적입니다.
• release 브랜치: 릴리스 준비를 위한 브랜치입니다. develop 브랜치에서 생성되며, 버그 수정, 문서화 등 릴리스 관련 작업을 수행합니다. 완료되면 main과 develop 브랜치 모두에 병합됩니다. release/<버전명> 형태로 명명합니다.
• hotfix 브랜치: 프로덕션 환경에서 발생한 긴급 버그를 수정하기 위한 브랜치입니다. main 브랜치에서 생성되며, 수정 완료 후 main과 develop 브랜치 모두에 병합됩니다. hotfix/<버전명> 형태로 명명합니다.

2. 협업 워크플로우 (Gitflow 예시)

가장 널리 사용되는 워크플로우 중 하나인 Gitflow를 기반으로 설명합니다.

1. 새로운 기능 개발: develop 브랜치에서 feature 브랜치를 생성합니다 (git checkout -b feature/my-new-feature develop).
2. 기능 개발 및 커밋: feature 브랜치에서 코드를 작성하고 자주 커밋합니다. 원격 저장소에도 주기적으로 푸시합니다 (git push origin feature/my-new-feature).
3. 기능 완료 및 병합 요청: 기능 개발이 완료되면, feature 브랜치를 develop 브랜치로 병합하기 위한 Pull Request (PR) 또는 Merge Request (MR)를 생성합니다.
4. 코드 리뷰: 팀 동료가 PR/MR을 검토하고 피드백을 제공합니다. 필요한 경우 수정 후 다시 푸시합니다.
5. develop 브랜치로 병합: 코드 리뷰가 통과되면, feature 브랜치를 develop 브랜치로 병합합니다.
6. 릴리스 준비: 다음 릴리스 시점이 되면, develop 브랜치에서 release 브랜치를 생성합니다 (git checkout -b release/v1.1.0 develop).
7. 릴리스 브랜치 안정화: release 브랜치에서 최종 버그 수정 및 테스트를 진행합니다.
8. 릴리스 및 main 브랜치 업데이트: 릴리스 준비가 완료되면, release 브랜치를 main 브랜치와 develop 브랜치 모두에 병합합니다. main 브랜치에는 태그를 추가합니다 (git tag -a v1.1.0 -m 'Version 1.1.0').
9. 긴급 버그 수정 (Hotfix): 프로덕션(main)에서 심각한 버그가 발견되면, main 브랜치에서 hotfix 브랜치를 생성합니다 (git checkout -b hotfix/fix-critical-bug main).
10. hotfix 병합: 수정 완료 후 hotfix 브랜치를 main과 develop 브랜치 모두에 병합하고, main에 새 태그를 추가합니다.

3. 브랜치 명명 규칙

• main, develop, release/*, hotfix/*, feature/* 와 같이 유형을 명확히 합니다.
• 기능명, 버그명, 버전명 등은 의미를 명확히 하는 소문자, 하이픈(-)을 사용합니다. (예: feature/user-authentication, hotfix/login-crash, release/2.3.1)

4. Pull Request (PR) / Merge Request (MR) 워크플로우

• 작은 단위로 PR 생성: 한 번에 너무 많은 변경 사항을 포함하는 PR은 리뷰 부담을 증가시킵니다. 기능별, 작업별로 작게 나누어 PR을 생성하는 것이 좋습니다.
• 명확한 PR 설명: PR의 목적, 변경 내용, 관련 이슈 등을 상세하게 작성합니다.
• 코드 리뷰 필수: 팀원 간의 코드 품질 향상 및 지식 공유를 위해 코드 리뷰는 필수 과정으로 포함합니다.
• 자동화된 테스트: CI/CD 파이프라인을 통해 PR 병합 전 자동화된 테스트를 실행하여 코드 안정성을 확보합니다.

5. 주의사항

• main 브랜치 직접 커밋 금지: main 브랜치에는 항상 안정적인 코드만 존재해야 하므로, 직접적인 커밋이나 푸시는 피해야 합니다.
• 충돌 관리: 병합 시 충돌이 발생하면, 해당 브랜치에서 최신 develop 또는 main 브랜치를 rebase/merge하여 충돌을 해결한 후 PR을 다시 제출합니다.
• 팀원과의 소통: 브랜치 전략과 워크플로우는 팀의 특성에 맞게 조정될 수 있습니다. 팀원들과 충분히 논의하고 합의된 규칙을 따르는 것이 중요합니다.

이 가이드라인을 따르면 Git을 더욱 효율적으로 활용하고 팀 프로젝트의 생산성을 크게 향상시킬 수 있습니다.