Git 브랜치 관리 전략

Git Flow 전략은 제외합니다. 최근에 포스팅을 했기 때문에.

 

1. GitHub Flow

GitHub Flow는 단순하고 가벼운 브랜치 전략으로, 지속적 배포(Continuous Deployment)에 적합합니다.

특징

• main 브랜치만 존재하며, 항상 배포 가능한 상태를 유지.
• 모든 작업은 feature 브랜치에서 이루어지고, 작업 완료 후 main에 병합.
• 병합 시 코드 리뷰와 자동화된 테스트를 반드시 수행.

흐름

1. main에서 feature 브랜치 생성.
2. 작업 완료 후 Pull Request 생성.
3. 코드 리뷰와 테스트 통과 후 main에 병합.
4. 병합 후 바로 배포.

사용 시기

• 배포 주기가 짧고, 빠른 릴리스가 중요한 프로젝트.
• 단순한 워크플로우를 선호하는 소규모 팀.

 

2. GitLab Flow

GitLab Flow는 GitHub Flow를 기반으로 개선된 전략으로, 환경별 브랜치(예: staging, production)를 사용하는 것이 특징입니다.

특징

• main 브랜치 외에 staging이나 production 브랜치를 사용하여 배포 프로세스를 관리.
• 배포 환경에 따라 병합 시점을 명확히 구분.

흐름

1. feature 브랜치에서 개발.
2. 작업 완료 후 main에 병합.
3. 자동화된 테스트가 통과되면 staging 브랜치로 병합하여 QA 테스트.
4. QA 완료 후 production 브랜치로 병합하여 실제 배포.

사용 시기

• 여러 배포 환경(테스트, 프로덕션 등)을 관리해야 하는 프로젝트.
• 중간 QA 단계가 필요한 팀.

 

3. Trunk-Based Development

Trunk-Based Development는 브랜치 사용을 최소화하고, main 브랜치를 중심으로 작업하는 전략입니다.

특징

• 모든 작업이 main 브랜치에서 이루어지거나, 짧게 유지되는 브랜치에서 작업 후 바로 병합.
• 브랜치는 짧은 생명 주기를 가짐.
• 지속적 통합(Continuous Integration, CI)과 지속적 배포(Continuous Deployment, CD)에 최적화.

흐름

1. main에서 바로 작업하거나, 단기 브랜치 생성.
2. 작업 완료 후 빠르게 main에 병합.
3. 배포 자동화 프로세스를 통해 즉시 배포.

사용 시기

• 배포 주기가 매우 짧은 프로젝트.
• CI/CD 환경을 적극적으로 활용하는 팀.

 

 

4. Forking Workflow

Forking Workflow는 오픈 소스 프로젝트에서 주로 사용하는 전략입니다.

특징

• 각 개발자가 프로젝트를 **포크(fork)**하고, 자신의 복제본에서 작업.
• 작업 완료 후 Pull Request를 통해 병합 요청.

흐름

1. 중앙 저장소를 포크하여 자신의 저장소 생성.
2. 자신의 저장소에서 브랜치를 만들어 작업.
3. 작업 완료 후 중앙 저장소에 병합 요청(Pull Request).

사용 시기

• 오픈 소스 프로젝트나 비공개 협업 프로젝트.
• 여러 외부 기여자와 협업하는 경우.