기술블로그-Flask편

🚀 Git Flow 브랜치 전략 초기 셋팅 가이드(1-1)

Chansman 2025. 4. 24. 12:42

🚀 Git Flow 브랜치 전략 초기 셋팅 가이드

목표: main, develop, feature, release, hotfix 브랜치 체계 구축!

✅ Step 1. 기본 브랜치 만들기

1️⃣ main 브랜치

  • GitHub 레포를 생성하면 기본으로 main 브랜치가 있어요.
  • 이건 그대로 두면 됩니다! (배포용 브랜치)

2️⃣ develop 브랜치 생성

모든 개발의 중심 브랜치!

git checkout -b develop
git push origin develop
  • GitHub에 가보면 이제 main과 develop 브랜치가 생겼을 거예요.

✅ Step 2. 브랜치 전략에 따라 작업하기

🔹 3️⃣ feature 브랜치 작업 방법

새로운 기능 개발 시 사용하는 브랜치

  1. 항상 develop 브랜치에서 시작! (첫시작일때 -b 를 통해 생성)
  2. git checkout 브랜치 이동 + 파일 체크아웃 + 브랜치 생성 등에만사용
git checkout develop
git pull   # 최신 코드 가져오기
git checkout -b feature/기능명

 

   2. 중간에 다시 브랜치 이동하는방법 ( merge전):

git switch feature/routes

 

git branch # 모든 브랜치 확인

 

2.작업 완료 후:

git add .
git commit -m "feat: 기능 설명"
git push origin feature/기능명

 

3.GitHub에서 PR(Pull Request) 생성 ➡️ develop으로 병합 요청!

 병합(Merge) 방법

🔹 방법 1: GitHub에서 PR(Pull Request) 로 병합 (✅ 추천)

  • 협업할 때는 무조건 PR로 병합하는 게 좋아요!
  • 팀원들이 코드 리뷰하고 안전하게 합칠 수 있어요.

순서:

  1. GitHub 들어가서 ➡️ Compare & pull request 클릭
  2. Base 브랜치: develop
    Compare 브랜치: feature/routes
  3. 병합(Merge) 버튼 클릭!

🔹 4️⃣ release 브랜치 사용법

배포 준비할 때 사용하는 브랜치 (기능 개발 끝난 후!)

  1. develop에서 분기:
git checkout develop
git pull
git checkout -b release/v1.0.0
  1. 배포 전 버그 수정 등 마무리 작업
  2. 완료되면:
git checkout main
git merge release/v1.0.0
git push origin main
  1. 다시 develop에도 병합:
git checkout develop
git merge release/v1.0.0
git push origin develop

🔹 5️⃣ hotfix 브랜치 사용법

배포된 버전(main)에서 긴급 수정이 필요할 때!

  1. main에서 분기:
git checkout main
git pull
git checkout -b hotfix/issue-001
  1. 수정 작업 후:
git add .
git commit -m "fix: 긴급 수정 내용"
git push origin hotfix/issue-001
  1. 병합:
git checkout main
git merge hotfix/issue-001
git push origin main

git checkout develop
git merge hotfix/issue-001
git push origin develop

🚨 브랜치 생성 요약

브랜치명생성 기준용도
main 기본 최종 배포본
develop main 개발 통합
feature/* develop 기능 개발
release/* develop 배포 준비
hotfix/* main 긴급 수정

✅ Step 3. GitHub 브랜치 보호 설정 (선택)

  • main, develop 브랜치는 실수로 직접 push 못하게 막을 수 있어요!
  1. GitHub 레포 → Settings → Branches
  2. Branch protection rules 설정
    • PR로만 병합 가능하게 설정 추천

🎯 정리: 초기 셋팅 순서

1️⃣ develop 브랜치 생성
2️⃣ 팀원들과 브랜치 규칙 공유
3️⃣ feature 브랜치로 기능 개발 시작
4️⃣ 배포 단계에서 release 브랜치 사용
5️⃣ 긴급 수정 시 hotfix 브랜치 활용

 

✅ 브랜치를 처음부터 다 만들어도 될까?

🔹 1. main & develop

👉 처음부터 반드시 만들어야 하는 브랜치!

  • 이 두 개는 프로젝트 시작과 동시에 필수로 세팅!
  • 협업의 중심축이 되는 브랜치이기 때문에, 초기에 무조건 있어야 해요.

🔹 2. feature 브랜치

❌ 처음부터 만들 필요 없음!

  • feature 브랜치는 "필요할 때 그때그때" 만드는 게 원칙이에요.
  • 이유:
    • 기능마다 이름이 다 다름 (feature/models, feature/routes 등)
    • 누가 어떤 작업을 할지 정해진 후 생성해야 깔끔!
    • 미리 만들어두면 쓸데없는 브랜치만 늘어나서 관리가 번거로워져요.

🔹 3. release 브랜치

❌ 절대 미리 만들지 않아요!

  • release 브랜치는 말 그대로 "배포 준비가 될 때" 만드는 브랜치예요.
  • 아직 개발도 안 했는데 release 브랜치를 만들어두면 의미가 없어요.
  • 버전명(release/v1.0.0)도 개발이 완료된 시점에 정하는 게 맞습니다.

🔹 4. hotfix 브랜치

❌ 미리 만들면 안 되는 브랜치!

  • hotfix는 긴급 상황에서만 사용하는 브랜치예요.
  • 배포된 코드(main)에서 문제가 생겼을 때 즉시 생성!
  • 미리 만들어두면 오히려 헷갈리고, 쓸모없는 브랜치가 됩니다.