Git Flow

협업을 하다 보면 "브랜치 이름을 바꿔야 할 때"가 생기고, "Git Flow 전략"을 따라야 혼선이 줄어듭니다. 이 글은 실제 프로젝트 흐름에 맞춰 브랜치 이름을 바꾸는 법과 Git Flow 브랜치 전략을 완벽하게 정리한 실전 가이드입니다.

---

1️⃣ 브랜치 이름을 바꿔야 하는 이유

• 브랜치 이름에 오타가 났다.
• 브랜치 목적이 바뀌었다.
• 팀 컨벤션을 따르지 않았다.

이유가 어찌 되었든, 이미 원격에 푸시한 브랜치의 이름을 바꾸는 과정은 로컬 + 원격 모두 신경 써야 합니다.

---

2️⃣ 브랜치 이름 변경 방법 (로컬 + 원격)

예시 상황:

• 기존 이름: feature/welcome_page_Ui
• 새 이름: feature/welcome-page-ui

▶︎ 순서 요약

# 1. 현재 브랜치 이름 확인
git branch

# 2. 로컬 브랜치 이름 변경
git branch -m feature/welcome-page-ui

# 3. 기존 이름의 원격 브랜치 삭제
git push origin --delete feature/welcome_page_Ui

# 4. 새 이름으로 푸시
git push origin feature/welcome-page-ui

# 5. 추적 브랜치 설정 (업스트림 연결)
git push --set-upstream origin feature/welcome-page-ui

💡 주의: 이미 PR을 올린 상태라면, PR도 새 브랜치 기준으로 다시 생성하는 것이 안전합니다.

---

3️⃣ Git Flow 브랜치 전략이란?

깃 플로우는 팀 협업에서 작업을 나누고 충돌을 줄이기 위한 브랜치 관리 전략입니다.

주요 브랜치 역할

브랜치 역할

main	실제 운영 배포가 되는 최종 코드
develop	개발자들이 기능을 병합하는 브랜치
feature/	하나의 기능 개발 단위를 위한 브랜치 (로그인 기능, 채팅기능 등)
bugfix/	개발 중 발견된 버그를 고치는 브랜치
hotfix/	배포 후 긴급하게 처리해야 할 문제 수정 브랜치
release/	배포 전 QA/테스트, 버전 업데이트를 위한 브랜치

---

4️⃣ 실전 Git Flow 명령어 흐름

✅ 기능 개발 시작

# 메인 or 디벨롭 기준 브랜치에서 시작
git checkout develop
git pull origin develop

# 기능 브랜치 생성
git checkout -b feature/chat-page

---

✅ 작업 후 커밋 및 푸시

# 파일 수정 후 커밋
git add .
git commit -m "채팅 페이지 UI 구현"

# 원격 브랜치 푸시
git push origin feature/chat-page

---

✅ PR 생성 및 머지

• GitHub에서 Pull Request 생성
• 코드 리뷰, 테스트 진행
• develop 브랜치로 머지

---

✅ 브랜치 정리 (중요)

# 로컬 브랜치 삭제
git branch -d feature/chat-page

# 원격 브랜치 삭제
git push origin --delete feature/chat-page

브랜치 삭제는 의무는 아니지만, 깔끔한 협업을 위해 강력히 권장됩니다.

---

5️⃣ 브랜치 작명 규칙 (케밥 케이스 권장)

브랜치 타입 예시

feature/	feature/chat-page-ui, feature/login-api
bugfix/	bugfix/navbar-overflow, bugfix/date-format
hotfix/	hotfix/firebase-token, hotfix/crash-on-boot
release/	release/v1.0.0, release/v2.1.3

---

🔁 Git Flow를 자동화하고 싶다면?

git-flow CLI를 사용하면 초기 설정부터 브랜치 생성까지 자동화가 가능합니다.

# 설치
brew install git-flow

# 초기 설정
git flow init

이후 다음 명령어로 기능 브랜치를 생성할 수 있습니다:

git flow feature start chat-page-ui

---

마무리: 정리는 효율을 만든다

• 브랜치 이름을 명확히 바꾸는 것만으로도 협업의 명확성이 커집니다.
• Git Flow 전략은 혼자 할 때도, 여럿이 할 때도 무조건적인 기준점이 되어줍니다.
• 팀의 브랜치 전략을 정리해서 Notion이나 README에 명시하는 것을 추천합니다.