[Codeit Sprit]Weekly Paper 2-1 Git 브랜치 전략

DreamPaste·2025년 4월 12일

GITHUB-FLOW git git flow gitlab-flow 브랜치 전략

Weekly Paper

목록 보기

3/8

git 브랜치 전략이란?

Git 브랜치 전략(Git Branch Strategy)은
여러 개발자가 협업하면서 코드를 효율적으로 관리하고 통합하기 위해
브랜치를 어떻게 만들고, 관리하고, 병합할지를 정하는 규칙과 흐름입니다.

왜 필요할까?

🔁 여러 기능을 동시에 개발할 때 충돌 없이 작업하기 위해
🧪 배포용 코드와 개발용 코드를 분리하기 위해
📦 릴리즈 주기에 맞춰 코드 관리하기 위해
💻 팀원 간 협업을 일관된 방식으로 하기 위해

1. Git Flow

🌿 Git Flow의 핵심 브랜치 구조

Git Flow는 총 5가지 브랜치를 사용하여 작업을 분리합니다.

main: 운영 환경에 배포되는 안정된 코드를 관리합니다.
develop: 다음 릴리즈를 위한 개발 브랜치입니다.
feature: 새로운 기능을 개발하는 브랜치로, develop브랜치에서 분기하여 작업 후 다시 develop에 병합됩니다.
realease: 릴리스 준비를 위한 브랜치로, 버그 수정 및 문서 작업이 이루어집니다.
hotfix: 운영 중 긴급한 버그 수정을 위한 브랜치로, main에서 분기하여 수정 후 main과 develop에 병합됩니다.

💻 Git Flow 사용 예시

회원가입 기능을 구현하는 간단한 프로젝트를 만든다고 가정해봅시다.
~~커밋 내용은 느낌대로 적었습니다...~~

먼저 git 저장소를 초기화합니다.
```
git init
```
main 브랜치에서 기능 개발을 시작하기 위해 develop 브랜치를 생성합니다.
```
git checkout -b develop
```

회원가입 기능을 구현하기 위해, feature/signup 브랜치를 생성합니다. 이후 작업을 시작합니다.

git checkout -b feature/signup
git commit -m "feat: Add signup form UI"
git commit -m "feat: Connect sign-up API"

회원가입 기능을 잘 구현했다면 develop 브랜치에 병합합니다.

git checkout develop
git merge --no-ff feature/signup # --no-ff 는 Fast Foward 없이 병합하라는 옵션입니다.
# fast-foward를 사용하지 않으면 병합 커밋을 생성하여 히스토리를 명확하게 유지합니다.
git branch -d feature/signup # feature 브랜치 삭제

배포를 준비하기 위해 release 브랜치를 생성합니다. 이 단계에서 발견된 버그를 수정하거나 문서를 보완합니다.
```
git checkout develop
git checkout -b release/v1.0.0
git commit -m "fix: Fix signup errors.."
git commit -m "docs: Readme 수정.."
```

배포 준비가 완료되면 release 브랜치를 main 과 develop에 병합합니다.

# main 브랜치로 병합
git checkout main
git merge --no-ff release/v1.0.0
git tag -a v1.0.0 -m "Release version 1.0.0"

# develop 브랜치로 병합
git checkout develop
git merge --no-ff release/v1.0.0

배포 후 긴급한 버그 수정이 필요한 경우, hotfix 브랜치를 사용합니다.

git checkout main
git checkout -b hotfix/v1.0.1
git commit -m "fix: Fix fatal CORS issue"

✅ Git Flow의 장단점

✅ 장점:

역할별로 브랜치를 분리하여 작업의 명확성을 높입니다.
릴리스 준비와 긴급 수정 작업을 체계적으로 관리할 수 있습니다.
협업 시 충돌을 최소화하고, 코드 품질을 유지할 수 있습니다.

❌ 단점:

브랜치가 많아져 관리가 복잡해질 수 있습니다.
빠른 배포가 필요한 환경에서는 오히려 비효율적일 수 있습니다.
CI/CD 파이프라인과의 통합이 복잡할 수 있습니다.

2. Github Flow

🚀 Github Flow란?

Github Flow는 Github에서 오픈소스와 협업 프로젝트를 위해 만든 단순한 브랜치 전략입니다.

“언제든지 배포 가능한 상태를 유지하면서, 기능을 브랜치에서 안전하게 개발하고 Pull Request로 병합한다” 는 철학을 따릅니다.

🌱 Github Flow의 기본 원칙

1️⃣ main은 항상 배포 가능한 상태여야 한다
2️⃣ 기능이나 수정은 새 브랜치(feature/...) 에서 작업한다
3️⃣ 기능 구현이 끝나면 Pull Request(PR) 를 만든다
4️⃣ 코드 리뷰 및 테스트 후 main에 병합한다
5️⃣ 병합되면 자동 배포(CI/CD) 되도록 설정한다

✍️ Github Flow 예시

동일하게 회원가입 기능을 개발합니다.

main에서 브랜치 생성

git checkout -b feature/signup

회원가입 코드 작성 후 커밋

git commit -m "feat: implement sign-up form and API"

GitHub에 푸시 & PR 생성

git push origin feature/signup

Pull Request 생성 → 코드 리뷰
PR 승인 → main에 병합 (squash merge 사용 권장)
CI/CD를 통해 자동 배포

git flow 보다 간결합니다.

✅ GitHub Flow의 장단점

✅ 장점

단순하고 빠르다
자동 배포와 잘 맞는다
실시간 협업에 유리하다

❌ 단점

릴리즈/버전 관리가 부족하다
복잡한 QA 프로세스와는 안 맞을 수 있다
긴 개발 사이클에는 적합하지 않음

3. Gitlab Flow

GitLab Flow란?

Git Flow의 브랜치 구조 + GitHub Flow의 단순한 병합 흐름 + 이슈(issue) 기반 개발을 통합한 Git 브랜치 전략입니다.

✅ 릴리즈 브랜치 관리 가능 (Git Flow)

✅ 간단한 머지 방식 (GitHub Flow)

✅ GitLab의 이슈, Merge Request, CI/CD 기능과 잘 연동됨

🔧 GitLab Flow의 3가지 방식

GitLab Flow는 사용하는 목적에 따라 여러 방식으로 사용할 수 있습니다.

Production 브랜치 기반 모델
- main 브랜치만 배포 대상
- feature/* 브랜치에서 작업 → PR 후 main 병합 → 배포
- GitHub Flow와 유사
Environment 기반 모델
- main, staging, production 등 환경별 브랜치 구분
- 각 환경에 맞춰 병합 및 배포
- main → staging → production
Release 기반 모델
- release/x.x 브랜치로 릴리즈를 따로 관리
- Git Flow의 릴리즈 관리 방식과 유사

✅ GitLab Flow의 장단점