깃 브랜치 전략

왜 필요 한가

• 코드 관리의 효율성>안정적인 프로덕션 환경

• 작업의 독립성> 코드 충돌 최소화

• 안정성 유지> 개발 속도 향상

• 코드 리뷰 및 품질 관리> 코드 품질 향상

• 배포 및 롤백의 용이성

---

Feature Branch

각 기능별로 독립적인 브랜치를 생성하여 작업
서로 작업에 영향을 주지 않고 효율적으로 협업

1. 기능별로 브랜치 생성
git checkout -b feature/new-feature
git checkout -b feature/login


2. 작업 진행
git add 파일들
git commit -m "커밋 내용"


3. 원격 저장소에 푸시
git push origin feature/new-feature


4. 병합(merge)
git checkout master git merge --no-ff feature/new-feature
git branch -d feature/new-feature

---

Github Flow

규모가 작거나 중간 크기의 프로젝트에 적합

빠른 개발 주기와 지속적인 배포에 초점

1. 브랜치 생성

   • 기준 브랜치에서 새로운 브랜치 생성

   • 브랜치 명은 작업 내용을 설명하는 명칭

   • 기준 브랜치는 항상 배포 가능한 상태

2. 작업 진행

3. 원격 저장소 push

4. PR(PullRequest) 생성 -> 코드 리뷰 후 브랜치 병합, PR 종료

---

Git Flow

프로젝트 코드 관리와 릴리즈를 체계적으로 진행하는 방법론

• Master: 프로덕션 환경에 배포되는 안정적인 코드가 저장되는 브랜치

• Develop: 개발 중인 코드를 관리하는 브랜치

• Feature: 새로운 기능 개발을 위한 브랜치(Dev 브랜치로부터 분기)

• Release: 새로운 버전 릴리스를 준비하는 브랜치(Dev 브랜치로부터 분기)

• Hotfix: 긴급한 버그 수정을 위한 브랜치(Master 브랜치로부터 분기)

1. 신규 기능 개발

   • Develop 브랜치에서 Feature 브랜치 생성

   • 기능 개발 완료 후 Develop 브랜치로 merge

2. 릴리즈 준비

   • Develop 브랜치에서 Release 브랜치 생성

   • 버전 번호를 부여하고, 문서 작업 등 릴리즈와 관련된 작업 진행

3. 릴리즈 확정

   • Release 브랜치를 Master 브랜치로 merge

   • 해당 커밋에 태그를 추가하여 릴리즈 버전 명시

   • 이후 Release 브랜치는 Develop 브랜치로 merge

4. 긴급한 버그 수정

   • Master 브랜치에서 발견한 버그는 Hotfix 브랜치를 생성해서 수정

   • 수정 완료 후 Master와 Develop 브랜치로 merge

---

Gitlab Flow

Git Flow의 복잡함과 Github Flow의 단순함을 보완한 브랜치 전략
master, feature, production 브랜치로 분류

• Feature

  • 새로운 기능 개발을 위한 브랜치

• Master

  • git flow develop 브랜치와 동일

  • feature 브랜치에서 병합된 기능에 대해 test 수행

• Production

  • gitflow의 master 브랜치와 동일한 배포 브랜치

  • test를 진행시 pre-production 브랜치로 test서버에 배포하여 검증함

---

전략 선정 기준

• 프로젝트 규모

• 개발 팀의 구성

• 개발 및 배포 주기

• 코드 안정성

Branching Strategy Explained | Atlassian