Git Flow 전략

프로젝트를 진행하다 보면 한 명의 개발자가 여러 기능을 동시에 구현하거나

여러 개발자가 같은 코드베이스를 함께 다루게 됩니다.

이때 가장 큰 문제는 충돌과 관리 복잡성입니다.
누가 어떤 기능을 언제 merge해야 하는가? 라는

명확한 기준이 없으면 코드 품질이 빠르게 무너집니다.

 

이를 해결하기 위한 체계적인 방법이 바로 Git 브랜칭 전략입니다.
오늘은 프로젝트에 적용할 Git flow 전략을 세워보았습니다.

 

---

 

Git Flow란?

Git Flow는 네덜란드 개발자 Vincent Driessen이 제안한 브랜칭 모델이라고 합니다.
이는 기능 개발(feature), 통합(develop), 배포(release), 긴급 수정(hotfix) 등
소프트웨어 개발 주기를 명확히 구분해주는 브랜치 전략입니다.

 

그럼 기본 구조를 살펴보겠습니다.

main (혹은 master) ← release ← develop ← feature/*
                                                       ↑ hotfix/*

 

• main (또는 master): 실제 서비스 운영 버전
• develop: 기능이 통합되는 기준 브랜치
• feature/: 새 기능을 개발하는 브랜치
• release/: 배포 전 검증 단계
• hotfix/: 긴급 수정

 

---

 

4단계 Git Flow 프로세스

1. 새 기능 시작

항상 새로운 기능 개발은 develop 브랜치에서 시작하도록 합니다.

git switch develop
git pull --ff-only                      # develop 최신화 (pull = fetch + merge --ff-only)

git switch -c feature/ai                # 새 기능 브랜치 생성 후 이동

• `--ff-only 옵션`은 fast-forward merge만 허용하는 안전한 방식입니다.
  원격에 있는 최신 커밋을 덮어쓰는 실수를 방지해 줍니다.

 

2. 팀 변경 반영

다른 팀원이 develop에 변경사항을 반영했을 때
작업 중인 feature 브랜치에도 그 내용을 반영해야 합니다.

 

반영하는 방식은 두 가지가 있습니다.

 

a) 커밋 후 머지 방식

git add -A
git commit -m "feat: ai 진행 중"

git switch develop
git pull --ff-only                      # 팀 변경 수신

git switch feature/ai
git merge develop                       # develop → feature/ai 병합
# 충돌 해결 → git add ... → git commit

 

b) 스태시 후 머지 방식 (작업 중이라 커밋하기 애매한 경우)

git stash push -u -m "ai-wip"           # 미추적 포함 스태시

git switch develop
git pull --ff-only                      # 팀 변경 수신

git switch feature/ai
git merge develop                       # develop → feature/ai 병합

git stash pop                           # 내 변경 복원
# 충돌 나면 해결 → git add ... → git commit -m "Resolve conflicts with develop"

 

•  `git stash`는 작업 중인 내용을 임시로 저장해두는 매우 유용한 기능입니다.
  특히 팀 작업 중 다른 브랜치로 이동할 때 자주 활용됩니다.

 

3. 기능 완료 직전 준비

기능 구현을 마쳤다면 develop을 한 번 더 최신화한 후 머지 준비를 합니다.

# 마지막 변경 반영
git add -A
git commit -m "feat: ai 기능 완료"

# 머지 직전 한 번 더 develop 최신 반영
git switch develop
git pull --ff-only

git switch feature/ai
git merge develop
# 충돌 해결 → git add ... → git commit

# 최초 푸시(-u로 업스트림 연결)
git push -u origin feature/ai

# GitHub에서 PR 생성: feature/ai → develop

• `git push -u origin feature/ai` 명령어는
  업스트림(upstream)을 설정해 이후 git push만 입력해도 자동으로 푸시됩니다.

 

4. PR 머지 후 정리

PR(Pull Request)이 리뷰 및 머지되면, 로컬과 원격 브랜치를 정리합니다.

git switch develop
git pull --ff-only                      # 머지된 내용 가져오기

git branch -d feature/ai                # 로컬 브랜치 삭제
git push origin --delete feature/ai     # 원격 브랜치 삭제(팀 정책에 따라)

git switch -c feature/sse               # 다음 작업 시작

• 머지 후 브랜치를 정리하면 저장소가 깔끔해지고 관리가 용이합니다.
  구현이 완료된 브랜치를 남겨두면 브랜치가 쌓여 협업 시 혼란을 초래할 수 있어 정리하는 것이 좋습니다.

 

---

 

명령어 정리

명령어	설명
git switch <branch>	해당 브랜치로 이동
git switch -c <branch>	새 브랜치 생성 + 이동
git branch -d <branch>	로컬 브랜치 삭제
git push -u origin <branch>	원격 브랜치에 푸시 및 업스트림 설정
git pull --ff-only	fetch + merge, 단 fast-forward만 허용
git merge <branch>	다른 브랜치를 현재 브랜치로 병합
git stash push -u -m "<메시지>"	추적＋미추적 파일 포함하여 스태시 저장
git stash pop	가장 최근 스태시를 복원
feature/*	새 기능 개발용 브랜치 네이밍 (예: feature/ai)
develop	팀 통합 기준선 브랜치

 

---

 

주의사항과 팁

• 충돌 관리: merge 전 반드시 git pull --ff-only으로 최신 상태 유지해야 한다.
• 작업 중 브랜치 전환 시: 커밋이 애매하면 git stash로 임시 저장하는 방식을 사용한다.
• PR 기준 통일: feature → develop 방향만 허용한다. (main 직접 수정 금지)
• 네이밍 규칙 통일
  • feat: 새로운 기능 추가
  • fix: 버그 수정
  • refactor: 코드 리팩토링
  • test: 테스트 코드 추가
  • chore: 빌드 도구나 보조 기능 수정