[Git-Github] 브랜치 전략

1. 브랜치 전략

소프트웨어 개발 팀이 코드를 작성, 병합 및 배포할 때 채택하는 전략이다.

 

(1) 필요성

여러 개발자가 하나의 브랜치에서 동시에 작업하고 변경 사항을 추가하면 코드 간 충돌이 심해지고 Merge하는 일이 복잡해질 수 있다.

 

(2) 목표

• 병렬 개발 체제 확립
• 계획적, 구조적 릴리즈 단계 구성

 

(3) Git 브랜치 전략

• Git Flow
• Github Flow

 

2. Git Flow

(1) 브랜치 구성

• main(=master): 제품 출시 버전 관리 브랜치
• feature: 새로운 기능 개발하는 브랜치
• develop: 다음 출시 버전을 위해 개발하는 브랜치
• release: 다음 출시 버전을 준비하는 브랜치
• hotfix: 출시된 제품의 버그를 고치기 위한 브랜치

 

(2) 브랜치 비교

• develop: 최신 코드가 merge되나, 실험적 기능 추가 가능한 브랜치
• main: 제품의 안정된 버전 유지되는 브랜치

 

(3) 브랜치 사용법

• 큰 흐름

main(시작) > develop(시작) > feature > develop(반영) > release > main(반영)

• 특별한 흐름
  • release(문제 발생) > release(문제 해결) > develop, main
  • hotfix > develop > main

 

3. Github Flow

(1) 브랜치 구성

• main: 배포를 위한 소스코드 관리하는 브랜치
• feature: 신규 기능 개발하는 브랜치

 

(2) 브랜치 사용법

feature > main

 

4. Git Flow VS Github Flow

• 복잡 VS 간단
  • Git Flow: 다양한 브랜치를 사용해 초기 설정 복잡
  • Github Flow: 두 개의 브랜치만 사용해 간단
• 느림 VS 빠름
  • Git Flow: 주요 기능 develop, 새로운 릴리즈 release 브랜치에 이루어져, 검증 또는 테스트 과정이 추가되기에 느림
  • Github Flow: 빠름
• 지속적 배포
  • Git Flow: 속도가 느려 긴 죽의 릴리즈 사이클이라면 어려움
  • Github: 속도가 빨라 가능, 단 main에서 배포를 관리하기에 여러 버전을 관리하는 것은 어려움
• 안전함 VS 위험함
  • Git Flow: 여러 과정을 거쳐 main에 merge되기에, 안전함
  • Github Flow: 하나의 과정을 거쳐 main에 merge되기에, 위험성 존재
• 프로젝트
  • Git Flow: 간단한 프로젝트
  • Github Flow: 복잡한 프로젝트 또는 여러 버전 관리가 필요한 프로젝트

 

5. Github Flow 사용 예시

🎯 BookBook 프로젝트