개발 초보자를 위한 Git 브랜치 전략: 기능 개발·버그 수정·배포를 브랜치로 깔끔하게 나누는 방법

개발을 막 시작했을 때 Git이 제일 헷갈리는 순간은 “어떤 브랜치에서 작업해야 하지?”입니다. 그냥 main에서 다 하면 빨라 보이지만, 기능 하나 추가하다가 급한 버그가 터지면 순식간에 커밋이 뒤엉키고, 배포 타이밍도 흐트러집니다. 브랜치를 역할별로 나누는 습관만 잡아도, 협업이든 혼자 개발이든 코드가 놀랄 만큼 정돈돼요.

브랜치를 나누는 기본 원칙 3가지

1. 배포 기준은 항상 명확하게: 배포 가능한 코드는 한 브랜치에만 둡니다. 보통 main(또는 master)입니다.
2. 작업 단위는 작게: 기능은 기능 브랜치, 버그는 버그 브랜치로 목적을 고정합니다.
3. 합치기(merge) 전에 리뷰/검증: 최소한 로컬 테스트라도 통과한 뒤 합칩니다.

추천 브랜치 구조 (초보자용 현실 조합)

1) main : 배포용(프로덕션)

• 사용자가 실제로 쓰는 버전
• 여기에는 즉시 배포 가능한 코드만 존재
• 직접 커밋은 피하고, PR/머지로만 반영하는 습관을 권장합니다.

2) develop : 통합 개발용(선택)

• 여러 기능이 모여서 다음 릴리스를 준비하는 공간
• 혼자 개발하고 배포가 잦다면 생략해도 됩니다.
• 팀 개발/기능이 많다면 develop이 완충지대 역할을 해줘요.

3) feature/* : 기능 개발용

• 예: feature/login, feature/profile-edit
• “이 브랜치의 목적은 오직 이 기능 하나”라고 딱 정해두면 커밋이 깔끔해집니다.

4) bugfix/* : 일반 버그 수정용

• 예: bugfix/null-pointer-on-home
• 아직 배포 전(develop)에서 발견된 버그를 잡을 때 사용

5) hotfix/* : 긴급 배포 버그용

• 예: hotfix/payment-crash
• 이미 배포된 main에서 터진 문제를 바로 고칠 때 사용
• 수정 후 main에 머지하고, 같은 수정이 develop에도 반영되도록 되돌려 머지하는 게 포인트입니다.

실제 흐름 예시: 기능 개발 → 통합 → 배포

기능 1개를 개발하는 표준 루틴

git checkout develop
git pull

git checkout -b feature/login
# 작업...
git add .
git commit -m "feat: 로그인 폼 및 API 연동"

git checkout develop
git merge feature/login
git push

• feature/login에서 개발하고
• 다 끝나면 develop으로 머지
• 기능이 충분히 모이면 main으로 배포 머지를 합니다.

배포할 때(예: v1.2.0)

git checkout main
git pull

git merge develop
git tag v1.2.0
git push --tags
git push

태그는 선택이지만, 나중에 “이 버전이 언제 배포됐지?”를 찾을 때 큰 도움이 됩니다.

긴급 장애 상황 예시: 배포된 버그를 즉시 수정(hotfix)

상황: 결제 화면에서 앱이 크래시. 오늘 바로 수정 배포가 필요.

git checkout main
git pull

git checkout -b hotfix/payment-crash
# 수정...
git add .
git commit -m "fix: 결제 크래시 예외 처리"

git checkout main
git merge hotfix/payment-crash
git tag v1.2.1
git push --tags
git push

git checkout develop
git merge hotfix/payment-crash
git push

여기서 핵심은 main과 develop 둘 다에 반영하는 것입니다. 안 그러면 다음 배포 때 버그가 “부활”하는 일이 생깁니다.

브랜치/커밋 메시지 네이밍 최소 규칙

브랜치 이름

• feature/기능-요약
• bugfix/원인-또는-증상
• hotfix/서비스영향-이슈

커밋 메시지(간단한 규칙만)

• feat: ... 기능 추가
• fix: ... 버그 수정
• refactor: ... 리팩터링(동작 변경 거의 없음)
• chore: ... 설정/잡일 예: fix: 홈 화면 진입 시 NPE 방지

초보자가 자주 하는 실수 4가지(그리고 해결)

1. 한 브랜치에서 기능+버그+리팩터링을 다 함 → 목적이 섞이면 리뷰도 어렵고 롤백도 힘듭니다. 한 브랜치=한 목적을 지키세요.

2. main에 바로 커밋 → 배포 브랜치는 안전지대여야 합니다. 꼭 브랜치 따서 머지하세요.

3. 긴급 수정 후 develop에 반영 안 함 → 다음 배포 때 다시 터집니다. hotfix는 “되돌려 머지”까지가 한 세트입니다.

4. 브랜치가 쌓이기만 하고 정리 안 함 → 머지 끝난 feature/*는 삭제하세요. 저장소가 훨씬 보기 좋아집니다.

마무리: “작게 나누고, 안전하게 합치기”

Git 브랜치 전략은 거창한 규칙을 외우는 게 아니라, 일이 꼬이지 않게 흐름을 만드는 습관입니다. 오늘부터는 main은 배포용으로 지키고, 기능은 feature/, 버그는 bugfix/, 긴급은 hotfix/*로만 나눠도 개발 경험이 한 단계 정리될 거예요.