인프라 기술 및 아키텍처/Github + Git, 전략, 컨벤션

03. Git Branch 전략 (Git flow)

Dev.99_tale 2025. 2. 15. 02:35

브랜치 전략이란

여러 개발자가 동시에 작업할 수 있도록 소스코드를 효율적으로 관리하는 방법이다.

주요 브랜치 전략

  • Git-flow
  • GitHub-flow
  • GitLab-flow

1. Git-flow

사용 시기 : 중대형 프로젝트나, 배포 주기가 명확하고 여러 기능을 병렬로 개발해야 할 때

 

언제 쓰나?

  • 여러 개발자가 동시에 작업하는 대규모 프로젝트에서 유용
  • 버전 관리가 명확하고, 각 단계별로 안정적인 배포가 요구될 때 사용
  • main (master): 배포 가능한 안정된 코드
  • develop: 새로운 기능 개발이 이루어지는 브랜치
  • feature: 특정 기능 개발을 위한 브랜치. develop에서 분기하여 작업
  • release: 배포 준비가 완료된 버전의 브랜치. QA와 버그 수정을 진행
  • hotfix: 배포된 버전에서 발생한 긴급 버그를 수정하는 브랜치

2. GitHub-flow

사용 시기 : 작은 팀이나 빠른 배포 주기가 필요할 때, 특히 지속적인 통합과 배포(CI/CD)를 사용할 때

 

언제 쓰나?

  • 작은 팀에서 빠르게 기능을 개발하고 배포할 때
  • 배포가 빈번하고, main 브랜치를 항상 안정적인 상태로 유지해야 할 때
  • main: 항상 배포 가능한 상태의 코드
  • 기능을 추가하거나 수정할 때마다 기능별 브랜치(e.g., feature-login 등) 생성
  • 작업 완료 후 Pull Request를 통해 main에 병합

3. GitLab-flow

사용 시기: 배포 환경을 더 세분화하고, 운영 환경과 개발 환경을 명확히 구분해야 할 때

 

언제 쓰나?

  • production과 staging을 분리하여 배포 환경을 철저히 관리할 필요가 있을 때
  • 안정성과 테스트를 강조하는 배포 전략에 적합
  • production: 실제 배포되는 코드
  • staging: 배포 전에 검증하는 브랜치
  • feature: Git-flow와 동일하게 각 기능을 위한 브랜치

 

이 중에서 Git - flow에 대해 자세히 다뤄보도록 하겠다.

 

Git - flow

1. Git-flow란

 주로 기능 개발, 릴리스, 배포를 관리하는 데 유용하며, 복잡한 프로젝트에서 여러 개발자가 협업할 때 쓰인다.

 핵심은 브랜치를 구분하여 각 작업을 독립적으로 진행하면서, 최종적으로 안정적인 버전을 유지하는 것이다.

2. Git Repository 구성

  • Upstream Repository: 팀이 공유하는 원격 저장소
  • Origin Repository: 개발자가 개인적으로 Fork한 원격 저장소
  • Local Repository: 개발자의 로컬 저장소
  • 실험적인 개발을 위해 Fork 방식 활용

3. Git-flow 브랜치 전략

  • Main 브랜치
    • main(master) : 출시 가능한 안정적인 브랜치
      • 항상 배포 가능한 상태의 코드만 포함되어야 한다. 이 브랜치는 실시간 배포가 이루어지는 브랜치로, 최종적으로 안정된 버전만 머지된다.
    • develop : 다음 출시 버전을 개발하는 브랜치
      • 기능 개발을 시작하는 기본 브랜치로, 여러 개발자들이 기능을 추가할 때 이 브랜치에서 작업을 시작한다. develop은 자주 변경되지만 항상 배포 준비가 가능한 상태여야 한다
  • 보조 브랜치
    • feature : 새로운 기능 개발 브랜치
      • 새로운 기능을 개발할 때 사용하는 브랜치이다. develop 브랜치에서 분기하여 기능 개발을 완료한 후 다시 develop으로 머지한다. 예를 들어, feature/login과 같은 형태로 명명된다.
    • release : 출시 준비 브랜치
      • 기능 개발이 완료된 후 릴리스를 준비하는 브랜치이다. 릴리스 브랜치는 develop 브랜치에서 분기하고, 버그 수정이나 마지막 손질을 진행한 후 master와 develop에 머지된다.
    • hotfix : 긴급 버그 수정 브랜치
      •  배포된 버전에서 긴급한 수정이 필요할 때 사용하는 브랜치이다. master에서 분기하여 수정 작업을 진행하고, 수정이 완료되면 master와 develop에 머지한다.

 

4. Git-flow 워크플로우

  1. 기능 개발
    • develop에서 feature 브랜치 생성 후 작업
    • 기능 완료 후 develop 브랜치로 Merge
  2. 릴리즈 준비
    • develop에서 release 브랜치 생성
    • QA 진행 및 버그 수정 후 master와 develop으로 Merge
    • master 브랜치에 버전 태그 추가 후 출시
  3. 긴급 수정
    • 출시 버전에서 버그 발생 시 hotfix 브랜치에서 수정 후 master와 develop으로 Merge

 

5. Git-flow의 실제 적용

  • 기능 개발 시 feature 브랜치 활용
  • develop에 머지될 기능들을 미리 release 브랜치에서 QA 진행
  • 필요할 경우 develop의 변경 사항을 feature 브랜치에 가져와 동기화

6. Git-flow 장단점

장점  단점
명확한 역할 분리
-  기능 개발, 릴리스 준비, 긴급 수정 등을 독립적으로 관리		 복잡성
- 많은 브랜치를 사용하므로 브랜치 관리가 복잡해짐
배포 관리 용이
- 배포 가능한 버전은 master에만 존재하여 배포 관리가 간편		 학습 곡선
- Git-flow의 규칙을 이해하고 적용하기까지 시간이 걸림
협업 최적화
- 여러 명의 개발자가 각자의 브랜치에서 작업하여 충돌을 최소화		 작은 프로젝트에 비효율적
- 작은 규모의 프로젝트에서는 불필요하게 복잡해짐

 

7.  결론

  • 복잡한 프로젝트에서 팀 간 협업과 배포 관리를 효율적으로 할 수 있는 강력한 브랜치 전략
  • 브랜치 수 증가로 관리 부담이 생겼지만, 보다 체계적이고 일관된 개발 가능
  • 기능 개발, 릴리스, 긴급 수정 등을 명확히 구분하여 작업가능
  • 상황에 맞게 Git-flow를 유연하게 적용하면서 최적의 브랜치 전략을 구축