AWS

Git Branch 전략이란?

프로젝트에서 여러 개발자들이 동시에 작업할 수 있도록 Git을 효율적으로 사용하는 방법

복잡한 소프트웨어 개발에 적합하며, 기능 개발과 배포, 긴급 수정 등을 구분하여 명확한 흐름을 유지 가능

주요 브랜치

main: 안정적인 코드가 유지되는 브랜치로, 항상 배포 가능한 상태를 유지해야 함
develop: feature에서 개발 된 기능들을 모아둔 브랜치로, 최종적으로 배포가 가능한 코드를 준비하는 브랜치
feature/*: 새로운 기능을 개발하기 위한 브랜치로, develop 브랜치에서 파생 및 develop 브랜치로 머지 병합
release/*: develop에서 파생되어 버그 수정 및 최종 준비 작업을 하는 브랜치로, 릴리즈 준비가 완료되면 main과 develop으로 병합
hotfix/*: 프로덕션 환경에서 긴급히 버그를 수정할 때 사용되는 브랜치로, main 브랜치에서 파생되며, 버그 수정 후 main과 develop으로 병합

Git Flow보다 간단하며, 지속적인 배포와 DevOps 환경에 적합
간단한 CI/CD 파이프라인을 지원하는 개발 모델

주요 브랜치

Git Flow와 GitHub Flow를 결합한 방식으로, 주로 GitLab을 사용하는 프로젝트에서 사용하는 방식

주요 브랜치

main: 안정적인 코드가 유지되는 브랜치로, 항상 배포 가능한 상태를 유지해야 함
feature/*: 새로운 기능을 개발하기 위한 브랜치로, main 브랜치에서 파생 및 main 브랜치로 머지 병합
staging: 최종 배포 전 테스트 하는 브랜치로, develop 브랜치가 있다면 develop 브랜치에서 파생되며, 없다면 main 브랜치에서 파생 및 병합
release/*: 릴리즈를 준비하는 브랜치로, develop 또는 staging 브랜치에서 파생되며 main 브랜치에 병합

여러 사람이 기능 개발 및 수정 후 바로 main 브랜치로 자주 병합하여 배포 가능 상태를 유지하는 방식

전략	장점	단점	적합한 프로젝트
Git Flow	- 체계적인 브랜치 관리로 안정성을 보장	- 브랜치 관리가 복잡하며 릴리즈 주기가 길어질 수 있음.	- DevOps 환경에 적합하지 않음
	- 단계별 작업 분리로 협업에 용이	- 대규모 팀과 긴 개발 주기	- 다단계 릴리즈가 필요한 프로젝트
GitHub Flow	-간단하고 빠른 배포가 가능	- 여러 단계의 QA나 릴리즈 프로세스를 지원하지 않음	- 대규모 팀에는 적합하지 않을 수 있음
	- 학습 곡선이 낮아 쉽게 도입 가능		소규모 팀, 짧은 개발 주기, DevOps 환경
GitLab Flow	- GitHub Flow보다 다양한 환경에 대응 가능	프로젝트에 따라 브랜치 구조가 복잡해질 수 있음	중규모 팀, 스테이징 환경이 필요한 프로젝트
	- 스테이징 및 릴리즈 브랜치로 QA 환경 제공
Trunk-Based Development	- 실시간 피드백과 빠른 배포가 가능	- 체계적인 QA 프로세스가 없으면 문제 발생 위험이 높음.	- 복잡한 작업 병합 시 충돌 관리가 필요
	- DevOps 환경 및 CI/CD와 잘 맞음		스타트업, 잦은 배포 및 릴리즈가 필요한 프로젝트