개발에서 Git을 사용한 브랜치 전략은 팀의 협업 방식과 릴리스 주기에 큰 영향을 미칩니다. 이 중에서도 많이 사용되는 두 가지 전략인 Git Flow와 GitHub Flow는 각기 다른 특성과 장점을 가지고 있습니다. 이번 포스팅에서는 두 가지 전략을 비교하고, 각 전략이 언제 적합한지 알아보겠습니다.
Git Branch 전략 비교
목차
Git Branch 전략
여러 개발자가 하나의 저장소에 작업을 할 때, 협업을 좀 더 효과적으로 하기 위해 Git Branch 에 대한 규칙을 정하고 저장소를 잘 활용하기 위한 workflow 를 정의하는 것을 바로 Git Branch 전략이라고 합니다. Git Branch 전략은 프로젝트의 관리와 배포의 안전성을 높이기 위해 적절하게 사용해야 합니다. Git Branch 전략은 대표적으로 Git Flow 전략과 Github Flow 전략이 있습니다.
Git Flow 전략
Git Flow는 Vincent Driessen이 제안한 브랜치 전략으로, 복잡한 프로젝트나 장기적인 개발 사이클에 적합합니다. 여러 가지 브랜치를 사용하여 기능 개발, 릴리스 준비, 긴급 수정 등의 작업을 체계적으로 관리합니다.
- Branch 종류
- master(main) : 실제 배포된 버전이 저장되는 브랜치로, 항상 안정적인 상태를 유지합니다.
- develop : 개발 중인 최신 코드가 모이는 브랜치입니다. 새로운 기능이나 버그 수정은 이 브랜치에서 시작됩니다. 개발의 중심이 되는 브랜치로 모든 기능이 정상적으로 동작할 수 있는 안정적인 상태를 유지합니다.
- feature : 새로운 기능을 개발할 때 사용하는 브랜치입니다. 기능 단위로 develop에서 분기하며, 개발이 완료되면 다시 develop으로 병합합니다. 이슈 넘버를 포함시켜 feature/#2-issue 형식으로 브랜치를 생성합니다.
- release : 릴리스를 준비하는 브랜치로, 버그를 수정하거나 새로운 기능을 포함한 상태로 안정화 및 QA를 진행합니다. 작업이 완료되면 master 브랜치에 병합되고, 동시에 develop에도 병합됩니다. 관례적으로 브랜치 이름 앞에 ' release-'를 사용합니다.
- Hotfix 브랜치 (hotfix/*): 배포한 후 긴급 버그 수정을 위해 master에서 분기되는 브랜치입니다. 빠르게 문제를 해결하고 master과 develop에 병합하고 브랜치를 삭제합니다. 관례적으로 브랜치 이름 앞에 'hotfix-'를 사용합니다.
- master(main) : 실제 배포된 버전이 저장되는 브랜치로, 항상 안정적인 상태를 유지합니다.
- 장점
- 안정성 : 릴리스와 개발 과정이 분리되어 안정적인 배포가 가능합니다.
- 분명한 작업 흐름 : 각각의 브랜치가 역할을 분명히 나누고 있어 팀원 간의 협업이 원활합니다.
- 장기 프로젝트에 적합 : 기능 추가, 릴리스 준비, 긴급 수정 등 다양한 작업을 병렬로 처리할 수 있습니다.
- 단점
- 복잡성 : 여러 브랜치 관리로 인해 작업이 복잡해질 수 있으며, 소규모 프로젝트나 짧은 배포 주기에서는 오히려 과도한 관리가 될 수 있습니다.
- 릴리스 주기 : 릴리스 브랜치가 포함되어 있어 빠른 배포 주기를 가지는 프로젝트에는 적합하지 않을 수 있습니다.
- 작업 흐름
- 신규 기능 개발 : feature 브랜치에서 작업 후 develop 브랜치에 merge
- 운영 서버에 배포 : realease 브랜치에서 QA 후 배포를 위해 master 브랜치에 merge (release 브랜치에서 오류 수정이 있었다면 develop 브랜치에도 merge)
- 배포 후 관리 : master 브랜치에서 버그가 발생되면, hotfix 브랜치 생성해 버그 픽스 후 master 브랜치와 develop 브랜치에 merge해 최신 코드 베이스와 동기화
GitHub Flow 전략
GitHub Flow는 GitHub에서 제안한 보다 단순한 브랜치 전략으로, 지속적인 배포(Continuous Delivery) 환경에서 유용합니다. Git Flow보다 단순한 구조를 가지고 있어 빠른 배포와 피드백이 필요한 프로젝트에 적합합니다.
- Branch 종류
- master(main) : 배포를 위한 소스 코드를 관리하는 브랜치로, 항상 배포 가능한 상태여야 합니다.
- feature : 새로운 기능 개발이나 버그 수정을 위한 브랜치로, master에서 분기됩니다. 개발이 완료되면 Pull Request를 통해 검토 후 master에 병합됩니다.
- 장점
- 단순함 : 브랜치 관리가 매우 간단해, 소규모 프로젝트나 빠른 배포 주기를 필요로 하는 프로젝트에 적합합니다.
- 빠른 배포 : 기능이 완성되면 바로 배포할 수 있어, 지속적인 배포(Continuous Delivery)와 완벽하게 어울립니다.
- 효율적인 코드 리뷰 : PR(Pull Request)를 통한 코드 리뷰 프로세스가 자연스럽게 이어집니다.
- 단점
- 복잡한 프로젝트에 부적합 : Git Flow에 비해 브랜치 전략이 단순하여, 여러 버전이나 복잡한 릴리스 주기를 관리하기 어렵습니다.
- 안정성 관리 : release나 hotfix 브랜치가 없어, 긴급 수정이나 대규모 릴리스 준비 시에는 추가적인 브랜치 관리가 필요할 수 있습니다.
- 작업 흐름
- master에서 기능 개발이나 버그 픽스를 위한 feature 브랜치 생성
- feature 브랜치에서 작업한 내용 commit
- 작업이 완료되면 PR(Pull Request)를 생성해 코드 리뷰
- 리뷰가 완료되면 master 브랜치로 merge
- master에 병합된 내용을 배포
Git Flow vs GitHub Flow: 언제 어떤 전략을 선택할까?
- Git Flow가 적합한 경우
- 대규모 프로젝트 : 복잡한 기능 개발, 다양한 릴리스 주기, 긴급 버그 수정 등의 다양한 요구 사항이 있는 경우.
- 긴 릴리스 주기 : 장기적으로 계획된 기능 업데이트와 안정성을 중요하게 여기는 경우.
- 여러 버전 관리 : 동시에 여러 버전의 애플리케이션을 유지보수해야 하는 경우.
- GitHub Flow가 적합한 경우
- 소규모 프로젝트: 단순한 브랜치 전략으로 빠르게 기능을 개발하고 배포할 수 있는 경우.
- 빠른 배포 주기: 지속적으로 작은 업데이트를 배포해야 하며, 빠른 피드백이 필요한 경우.
- CI/CD 환경: 자동화된 테스트 및 배포 파이프라인이 구축된 프로젝트.
Git Flow와 GitHub Flow는 각기 다른 장단점을 가지고 있어, 프로젝트의 규모와 릴리스 주기에 따라 적합한 브랜치 전략을 선택하는 것이 중요합니다. 대규모, 장기 프로젝트라면 Git Flow가 안정성을 제공할 것이고, 빠른 배포와 효율성을 추구하는 소규모 프로젝트라면 GitHub Flow가 더 적합할 것입니다.
프로젝트의 특성에 맞는 브랜치 전략을 선택하여 개발 효율성을 극대화해 보세요! 😊
추천글
2024.09.07 - [개발 공부 일지/Git] - Git
Git
Git Git 은 분산형 버전 관리 시스템으로 소프트웨어 개발 과정에서 소스 코드의 변경 사항을 추적하고 관리하는 데 사용됩니다. 버전관리 과제나 업무를 할 때 최종본, 최종본_a, 최종본_a_1 처럼
dev-hpk.tistory.com
2024.09.14 - [개발 공부 일지/Git] - [Git] Git Branch Merge 방법
[Git] Git Branch Merge 방법
Git에서 브랜치를 병합(merge)하는 방법은 여러 가지가 있으며, 프로젝트의 상황과 요구 사항에 맞게 적절한 방식을 선택하는 것이 중요합니다. 이번 포스팅에서는 Git에서 자주 사용되는 병합 방
dev-hpk.tistory.com
'개발 공부 일지 > Git' 카테고리의 다른 글
| [Git] Git Branch Merge 방법 (2) | 2024.09.14 |
|---|---|
| Git (3) | 2024.09.07 |