초보 개발자를 위한 Git 브랜치 전략: main·dev·feature를 나누고 Pull Request로 협업하는 가장 쉬운 흐름

처음 팀 프로젝트를 시작하면 Git이 “버전 관리 도구”에서 갑자기 “팀워크 도구”로 변합니다. 내가 고친 코드가 누군가의 작업을 덮어버리거나, 잘 되던 기능이 갑자기 깨지는 순간이 오죠. 이 글에서는 초보 개발자도 바로 적용할 수 있는 가장 단순한 3브랜치 전략(main·dev·feature)과 Pull Request(PR) 중심 협업 흐름을 정리합니다. 복잡한 규칙 대신, 안전하고 예측 가능한 작업 습관을 만드는 데 초점을 맞출게요.

브랜치 역할을 딱 3개로 고정하기

main: “항상 배포 가능한” 기준선

• 원칙: main은 깨지면 안 되는 브랜치입니다.
• 직접 커밋은 지양하고, 보통 PR로만 반영합니다.
• 작은 팀이라도 main이 안정적이면 마음이 편해집니다.

dev: 다음 배포를 준비하는 통합 공간

• dev는 여러 기능을 모아 통합 테스트를 하는 곳입니다.
• 기능 개발은 dev에서 바로 하지 않고, feature 브랜치에서 한 뒤 dev로 합칩니다.

feature/*: 기능 단위 작업 공간

• 새로운 기능/수정사항은 기능 단위로 브랜치 생성이 핵심입니다.
• 네이밍 예시:
• feature/login
• feature/profile-edit
• feature/fix-navbar

가장 쉬운 협업 흐름 (실전 단계)

1) 최신 dev에서 기능 브랜치 만들기

git checkout dev
git pull origin dev
git checkout -b feature/login

• 항상 최신 dev 기준으로 시작하면 충돌이 줄어듭니다.

2) 작업하고 “작게” 커밋하기

git add .
git commit -m "Add login form UI"
git commit -m "Implement login API integration"

• 커밋은 작고 의미 있게 쪼개면 리뷰가 쉬워집니다.
• 메시지는 “무엇을 했는지”가 드러나게 작성하세요.

3) 원격에 푸시하고 PR 열기 (feature → dev)

git push -u origin feature/login

PR에는 아래 3가지만 꼭 적어도 충분합니다.

• 변경 요약: 무엇을 구현/수정했는지
• 테스트 방법: 어떻게 확인했는지(예: 로그인 성공/실패 케이스)
• 스크린샷/로그: UI나 에러 수정이면 특히 도움이 됩니다

4) 리뷰 반영 → dev에 머지

• 리뷰 코멘트는 “지적”이 아니라 팀의 품질을 맞추는 과정입니다.
• 수정 커밋 후 같은 PR에 푸시하면 자동으로 갱신됩니다.

5) 배포 시점에 dev → main PR

• 기능들이 dev에서 안정화되면 main으로 PR을 올립니다.
• 이 PR은 “이번 배포 묶음”이라 생각하면 좋아요.

작은 팀/초보 팀이 자주 겪는 문제와 해결 팁

충돌(Conflict)이 무섭다

• 기능 브랜치를 오래 끌면 충돌 확률이 커집니다. 기능은 작게 쪼개고 PR을 자주 올리세요.

• 작업 중간에 dev 변경을 가져오고 싶다면:

git checkout feature/login
git fetch origin
git rebase origin/dev

• rebase가 어렵다면 merge로 시작해도 괜찮습니다. 중요한 건 자주 맞추는 습관입니다.

“급한 수정”은 어디서 하지?

• 배포된 main에서 긴급 수정이 필요하면 hotfix/*를 추가로 쓰기도 합니다. 다만 초보 팀이라면 우선 feature/fix-...로 dev에 반영 → 빠르게 main으로 배포 흐름부터 안정화하는 걸 추천합니다.

PR 리뷰는 뭘 봐야 할까?

초보 리뷰 체크리스트(최소 버전)

• 동작: 요구사항대로 동작하는가?
• 안전: 예외 처리/에러 메시지가 있는가?
• 가독성: 변수명/함수명이 의도를 말해주는가?
• 영향 범위: unrelated 파일 변경이 과하지 않은가?

예시 시나리오: 로그인 기능을 팀이 같이 만들 때

1. A가 feature/login-ui에서 화면을 만들고 PR → dev
2. B가 feature/login-api에서 API 연동하고 PR → dev
3. dev에서 함께 테스트(성공/실패/토큰 만료 등)
4. 이상 없으면 dev → main PR로 배포 이 흐름의 장점은 명확합니다. 누가 무엇을 작업 중인지 보이고, 문제가 생겨도 main을 지킬 수 있어요. 결과적으로 개발 속도보다 더 중요한 “팀의 안정감”이 생깁니다.

마무리: 규칙은 단순할수록 오래 갑니다

초보 팀에게 가장 좋은 Git 전략은 “멋진 전략”이 아니라 매일 지킬 수 있는 전략입니다. main은 안정적으로, dev는 통합 공간으로, feature는 기능 단위로. 그리고 모든 변경은 PR로 대화하며 합치기. 이 4가지만 지켜도 협업 스트레스가 눈에 띄게 줄어듭니다.