Git 브랜치 전략 - Git Flow, GitHub Flow

Git Flow 

제품 출시 버전, 개발 버전, 기능, 출시 준비, 버그 수정 등 다양한 브랜치를 관리하게 지원

브랜치 구성

Feature Branch

역할

• 새로운 기능 개발을 위한 브랜치
• 보통 develop 브랜치에서 분기하여 작업을 시작하고, 기능 개발 완료 후 develop 브랜치에 병합
• feature/login-page, feature/api-integration 등 기능 이름을 포함

 

Develop Branch

 역할

• 새로운 기능 개발, 버그 수정 등 모든 작업의 기반 브랜치
• 가장 활발히 작업하는 브랜치로, 실험적 코드와 아직 완전하지 않은 변경 사항이 포함됨

특징

• 안정적이지 않으며, 테스트가 완벽히 이루어지지 않은 상태의 코드 포함

 

Release Branch

역할

• 배포 전 최종 테스트 및 품질 보증(QA)을 위한 브랜치
• develop 브랜치에서 분기하며, 모든 버그가 수정되고 테스트를 통과하면 master 브랜치로 병합
• 테스트 중 발견된 버그는 release 브랜치에서 수정한 후 병합

 

Hotfix Branch

 

역할

• 프로덕션에서 발생한 긴급 버그 수정을 위한 브랜치
• master 브랜치에서 바로 분기하여, 수정 후 master 브랜치와 develop 브랜치로 병합
• hotfix/payment-error 처럼 작명

 

Master(Main) Branch

역할

• 실제 사용자가 접근하는 환경의 코드를 포함
• 이 브랜치는 반드시 안정적이고 배포 가능한 상태를 유지

특징

• 긴급 수정이 필요한 경우, hotfix 브랜치를 사용
• 버전 태그를 통해 배포 이력을 관리하는 경우가 많음

 

Flow

• 기능 개발을 위해, develop 브랜치로 부터 feature 브랜치 생성 후 작업. 작업 완료 후 develop 브랜치에 병합
• develop 브랜치는 feature 브랜치가 아니더라도 자유롭게 팀원들이 커밋 가능

 

• 다음 출시 버전을 위해 release 브랜치를 따서 배포 전 테스트
• 발견된 버그들은 release 브랜치에서 바로 수정하거나 develop 브랜치에서 수정 후 병합

 

 

• release 브랜치에서 테스트가 끝나면 Master 브랜치로 병합하여 제품을 출시

 

• 배포된 Master 브랜치에서 버그가 발생한 경우, hotfix 브랜치를 생성한 뒤, 버그를 수정하여 Master 브랜치와 develop 브랜치에 업데이트 

 

GitHub Flow 

master 브랜치와 feature 브랜치만으로 구성되어, 훨씬 간단하고 빠르게 수정 배포 할 수 있는 전략

브랜치 구성

Feature Branch

역할

• 새로운 기능 개발을 위한 브랜치
•  Master 브랜치에서 분기하여 작업을 시작하고, 기능 개발 완료 후 Master 브랜치에 병합
• feature/login-page, feature/api-integration 등 기능 이름을 포함

 

Master(Main) Branch

역할

• 실제 사용자가 접근하는 환경의 코드를 포함
• 이 브랜치는 반드시 안정적이고 배포 가능한 상태를 유지

특징

• 버전 태그를 통해 배포 이력을 관리하는 경우가 많음

 

Flow

• 신규 기능 개발 시, master 브랜치에서 직접 feature 브랜치를 만들어서 개발

 

• feature 브랜치에서 기능 개발이 완료되면 github 내에서 PR 리뷰 진행
• 문제가 없다고 판단되면 master 브랜치에 병합

 

차이점

• Git Flow는 안정성에서 강점을 가지므로, 대규모 프로젝트에 적합
• GitHub Flow는 단순성과 민첩성에서 강점을 가지므로, 소규모 프로젝트에 적합