🧪 실전 예제로 배우는 Git Flow 전략
- 기능 개발부터 릴리스, 버그 수정까지 한눈에 흐름 정리
📘 시나리오
지금부터 MyShop이라는 쇼핑몰 프로젝트에서 로그인 기능 개발 → 버전 릴리스 → 긴급 버그 수정이라는 흐름을 Git Flow 전략에 따라 진행해보겠습니다.
1️⃣ 프로젝트 초기화
# 기본 브랜치(main)는 이미 존재한다고 가정
git checkout -b develop
git push -u origin develop- main은 항상 배포 가능한 안정 코드
- develop은 다음 릴리스를 위한 통합 개발 브랜치
2️⃣ 기능 개발 (로그인 기능)
# develop에서 새로운 기능 브랜치 생성
git checkout develop
git checkout -b feature/login
# 로그인 기능 개발 작업
# 파일 수정, 커밋...
git add .
git commit -m "feat: 로그인 기능 구현"
# 기능 완료 후 develop에 병합
git checkout develop
git merge feature/login
git branch -d feature/login🔄 정리
- feature/login 브랜치에서 기능을 개발하고
- 완료되면 develop으로 병합 후 삭제
3️⃣ 릴리스 준비 (v1.0.0)
# release 브랜치 생성
git checkout develop
git checkout -b release/1.0.0
# 테스트 중 발견된 마이너 이슈 수정
git commit -am "fix: 로그인 버튼 색상 조정"
# 릴리스 완료 → main에 병합
git checkout main
git merge release/1.0.0
git tag -a v1.0.0 -m "🎉 Release v1.0.0"
# develop에도 병합 (테스트 수정사항 반영)
git checkout develop
git merge release/1.0.0
# release 브랜치 삭제
git branch -d release/1.0.0✅ main은 최신 배포 버전
✅ develop은 다음 기능 개발 준비 완료
4️⃣ 긴급 버그 수정 (v1.0.1)
배포 후 로그인 시 예외 발생 보고됨! 🔥
# main에서 hotfix 브랜치 생성
git checkout main
git checkout -b hotfix/login-crash
# 문제 수정
git commit -am "fix: 로그인 시 NullPointerException 발생 문제 해결"
# 수정 완료 → main에 병합
git checkout main
git merge hotfix/login-crash
git tag -a v1.0.1 -m "🔧 Hotfix: 로그인 버그 수정"
# develop에도 병합 (다음 개발에 반영)
git checkout develop
git merge hotfix/login-crash
# hotfix 브랜치 삭제
git branch -d hotfix/login-crash🔄 전체 흐름 요약
main
└─ release/1.0.0 → 🔀 merge → main + develop (릴리스)
└─ hotfix/login-crash → 🔀 merge → main + develop (버그 수정)
develop
└─ feature/login → 🔀 merge → develop (기능 개발)📌 브랜치별 용도 다시 보기
| 브랜치 | 용도 |
| main | 운영 중인 최종 코드 (배포 버전) |
| develop | 다음 릴리스를 위한 통합 개발 브랜치 |
| feature/* | 기능 단위 개발 (개발자 개인 작업 공간) |
| release/* | 배포 전 테스트/수정/버전 태깅 |
| hotfix/* | 운영 중 긴급 수정 및 패치 |
🧠 팁: Git Flow는 언제 쓰면 좋을까?
- ✅ 협업 인원이 3명 이상이고
- ✅ 기능/릴리스/버그 수정이 병렬적으로 발생하며
- ✅ 릴리스 주기가 명확히 존재할 때
이런 상황이라면 Git Flow는 버전 관리의 복잡성을 줄이고, 팀 간 충돌을 줄여줍니다.
✅ 마무리
Git Flow는 단순히 브랜치를 나누는 것이 아니라,
기능 개발, 테스트, 릴리스, 유지보수 작업의 전체 흐름을 시각적으로 설계하게 해줍니다.
실제 프로젝트에서도 이번 예시처럼
- 기능 단위로 feature/* 브랜치를 만들고
- 안정성 테스트를 release/*에서 진행하며
- 문제가 생기면 hotfix/*로 바로 대응하는 방식이
협업의 효율성과 서비스 안정성을 크게 높여줍니다.
'Git > GitHub' 카테고리의 다른 글
| Git Branch 전략 - Git Flow (0) | 2025.05.03 |
|---|---|
| GitHub - Image 올리기 (README, Issue, PR) (0) | 2021.08.22 |
