📌 [개인기록] Git 협업 및 브랜치 전략 정리

본 글에서는 서비스 운영 중인 프로젝트에서 Git을 활용한 협업 방식에 대해 정리하였습니다.
운영 배포는 main 브랜치를 기준으로 진행하며, 각 개발자는 개별 브랜치에서 작업 후 PR(Pull Request)을 통해 병합하는 방식입니다.
이 문서는 팀원들과의 원활한 협업을 위한 가이드로 활용할 수 있습니다.

---

1. Git 브랜치 전략

운영 프로젝트에서는 일반적으로 Git Flow 또는 GitHub Flow 전략을 활용할 수 있습니다.

1️⃣ Git Flow (운영/개발 분리 - 대규모 프로젝트에 적합)

✅ 브랜치 구조:

• main → 운영 배포 브랜치
• develop → 개발 통합 브랜치
• feature/* → 기능 개발 브랜치
• release/* → 배포 준비 브랜치
• hotfix/* → 운영 긴급 수정 브랜치

✅ 작업 방식:

1. 기능 개발 시 feature/기능명 브랜치를 develop에서 생성합니다.
2. 기능 개발이 완료되면 PR을 통해 develop 브랜치에 병합합니다.
3. 배포가 필요할 경우 release/버전명 브랜치를 생성하여 테스트를 진행한 후 main에 병합합니다.
4. 운영 중 긴급 수정이 필요한 경우 hotfix/버그명 브랜치를 main에서 생성하여 수정 후 반영합니다.

✅ 예시 흐름:

# 기능 개발 브랜치 생성
git checkout -b feature/login develop

# 개발 후 커밋 및 push
git commit -m "[feat] 로그인 기능 추가"
git push origin feature/login

# PR 후 코드 리뷰 → develop에 merge

 

📌 Git Flow는 팀 규모가 크거나 배포 주기가 긴 프로젝트에 적합합니다.

---

2️⃣ GitHub Flow (빠른 배포 - 가벼운 운영 프로젝트에 적합)

✅ 브랜치 구조:

• main → 운영 배포 브랜치
• feature/* → 기능 개발 브랜치

✅ 작업 방식:

1. 각 개발자는 feature/기능명 브랜치를 main에서 생성합니다.
2. 기능 개발이 완료되면 PR을 통해 main에 병합합니다.
3. 병합 후 자동 배포가 가능하도록 CI/CD를 적용할 수도 있습니다.

✅ 예시 흐름:

# feature 브랜치 생성
git checkout -b feature/cart-function main

# 개발 후 커밋 및 push
git commit -m "[feat] 장바구니 기능 추가"
git push origin feature/cart-function

# PR 후 코드 리뷰 → main에 merge

 

📌 GitHub Flow는 빠르게 기능을 배포해야 하는 프로젝트에 적합합니다.

---

2. Git 협업 프로세스

1️⃣ 작업 브랜치 생성

• main 또는 develop에서 feature/기능명 브랜치를 생성합니다.

git checkout -b feature/payment develop

 

2️⃣ 개발 진행 및 커밋

• 기능 개발 후 적절한 커밋 메시지를 작성합니다.

git commit -m "[feat] 결제 기능 추가"

 

📌 커밋 메시지 컨벤션 예시:

• [feat] 기능 추가
• [fix] 버그 수정
• [refactor] 코드 리팩토링
• [docs] 문서 수정

3️⃣ 원격 저장소에 Push

git push origin feature/payment

 

4️⃣ PR 생성 및 코드 리뷰 요청

• feature/기능명 → develop 또는 main으로 PR을 생성합니다.
• 팀원들에게 코드 리뷰를 요청합니다.

5️⃣ 코드 리뷰 후 병합

• 팀원들의 승인(Approvals)을 받은 후 develop 또는 main에 병합합니다.

6️⃣ 배포 준비 (release 브랜치 사용 시)

• develop에서 release/버전명 브랜치를 생성하여 QA 테스트를 진행합니다.

git checkout -b release/v1.0 develop
git push origin release/v1.0

• QA 테스트 완료 후 main에 병합하여 배포합니다.
• main에 배포한 이후, develop에도 병합합니다.

7️⃣ 운영 긴급 수정 (hotfix 브랜치 사용 시)

• 운영 중 버그 발생 시 main에서 hotfix/버그명 브랜치를 생성하여 수정합니다.

git checkout -b hotfix/login-bug main

---

3. 협업 시 소통 방식

1️⃣ GitHub/GitLab 이슈 및 PR 활용

• 개발할 기능은 이슈로 등록합니다.
• feature 브랜치를 생성한 후 PR을 올려서 코드 리뷰를 요청합니다.
• 리뷰어가 코드 피드백을 남기면 이를 반영하여 수정합니다.

2️⃣ 커밋 컨벤션 및 브랜치 네이밍 규칙

• 브랜치 네이밍: feature/login, hotfix/payment-bug
• 커밋 메시지 규칙: [feat], [fix], [chore]

3️⃣ 코드 리뷰 문화

• PR은 최소 1~2명 이상의 코드 리뷰 후 병합합니다.
• 리뷰어는 단순 승인(Approve)보다는 코드 개선을 위한 피드백을 제공하는 것이 좋습니다.

---

4. Git 브랜치 전략 선택 가이드

비교 항목	Git Flow	Github Flow
적용 대상	대규모 팀 프로젝트	소규모 팀, 빠른 배포
운영 브랜치	main, develop	main만 사용
배포 프로세스	release/* 사용후 main에 병합	main에 바로 병합
긴급 수정 방식	hotfix/* 브랜치	feature/*에서 수정후 바로 병합
장점	안정적인 배포 관리 가능	빠른 기능 배포 가능
단점	브랜치가 많아 복잡할 수 있음	운영 중 버그 핫픽스 시 혼란 가능

---

5. 결론

✅ 운영 배포는 main 브랜치에서 진행합니다.
✅ 각 개발자는 feature/* 브랜치에서 작업 후 PR을 생성합니다.
✅ 코드 리뷰 후 develop 또는 main에 병합합니다.
✅ 배포 시 release/* 브랜치를 활용합니다.
✅ 운영 버그는 hotfix/* 브랜치에서 수정하여 반영합니다.

🚀 Git Flow (대규모 프로젝트) vs GitHub Flow (빠른 배포) 선택 기준 🚀

• 팀 규모가 크고 배포 사이클이 길다면 → Git Flow를 활용합니다.
• 빠른 기능 배포가 필요한 경우 → GitHub Flow를 활용합니다.