개발자의 Git 브랜치 전략 일기

목차

2025년 10월 어느 날, 퇴근길 카페에서

"아니, 또 dev랑 main 헷갈렸어..."

오늘도 팀 코드 리뷰에서 브랜치 전략 관련 질문을 몇 개 받았다. 내가 만든 브랜치 이름이 feature였는데, 팀 브랜치 전략은 feat/작업명으로 하기로 했다고 한다. 헷갈린다. 머릿속엔 main, dev, feat가 왔다 갔다. 그래서 오늘은 정리해보기로 했다. 진짜 실무에서 헷갈리지 않도록 내가 쓰는 Git 브랜치 전략, 풀어본다.

 

Git Branch

브랜치는 세 가지만 기억하자: main, dev/mainline, feat/*

다음 구조로 Git 브랜치를 관리한다:

• main: 배포용 브랜치. 항상 안정된 버전이 올라간다.
• dev/mainline: 개발 통합 브랜치. 모든 기능이 이곳에 합쳐진다.
• feat/작업명: 기능별 브랜치. 내가 실제로 개발하는 브랜치다.

내가 외우는 방식:

feat/* → dev/mainline → main 순으로 올라간다.
개발은 feat에서 시작해서, 검증되면 dev/mainline으로, QA까지 끝나면 main으로 가는 여정.

 

Git 전략

일상적인 작업: dev/mainline에서 커밋하고 푸시하기

매일 하는 자잘한 수정이나 UI 조정 같은 작업은 feat 브랜치를 따지 않고 바로 dev/mainline에서 작업한다.

예를 들면:

git switch dev/mainline
git pull --rebase origin dev/mainline
# 코드 수정 후
git add -A && git commit -m "feat: 헤더 색상 조정"
git push

 

※ 포인트는 항상 git pull --rebase로 최신 코드를 기반으로 작업하는 거. 그래야 병합 커밋 없이 이력이 깔끔하다.

Git Branch, Checkout, switch

 

기능 개발: feat/로 브랜치 파서 작업하기

큰 기능이나 이슈가 있는 작업은 항상 feat 브랜치를 파서 한다. 예를 들어 lambda 마이그레이션 작업은 이렇게 시작했다:

git switch dev/mainline
git pull --rebase origin dev/mainline
git switch -c feat/lambda-migration
git push -u origin feat/lambda-migration

개발하다 milestone에 도달하면 태그도 남긴다

git tag -a v0.3.0-lambda.0 -m "lambda milestone 0"
git push origin v0.3.0-lambda.0

 

 

병합(Merge): 기능 브랜치 → dev/mainline

작업이 끝나면 다시 dev/mainline으로 돌아가 병합한다.

git switch dev/mainline
git pull --rebase origin dev/mainline
git merge --no-ff feat/lambda-migration -m "merge: lambda migration"
git push origin dev/mainline

※ --no-ff 옵션으로 merge 커밋을 남겨 기능 단위 작업이 눈에 띄게.

 

Source Deploy

배포 준비: dev/mainline → main으로 merge + tag

QA가 끝났으면 배포한다. 규모가 크면 release 브랜치 만들고 QA, 아니면 dev/mainline에서 바로 main으로 merge:

git switch main
git merge --no-ff dev/mainline
git tag -a v0.3.0 -m "0.3.0 GA"
git push origin main v0.3.0

 

※ 포인트는 항상 git pull --rebase로 최신 코드를 기반으로 작업하는 거. 그래야 병합 커밋 없이 이력이 깔끔하다.

긴급한 핫픽스는 main에서 바로 분기

배포 후 버그 발견? 그러면 main에서 핫픽스 브랜치 만들고 바로 수정한다:

git switch -c hotfix/0.3.1 v0.3.0
# fix...
git switch main && git merge --no-ff hotfix/0.3.1
git switch dev/mainline && git merge --no-ff hotfix/0.3.1
git tag -a v0.3.1 -m "0.3.1 hotfix"
git push origin main dev/mainline v0.3.1

 

※ 핫픽스는 main, dev/mainline 양쪽에 꼭 병합한다. 그래야 이후 작업에 반영된다.

 

Git Branching Strategy

마무리 생각

예전엔 "그냥 브랜치 하나 만들고 작업하면 되는 거 아냐?" 했는데, 팀에서 함께 하다 보니 왜 브랜치 전략이 중요한지 실감 난다. 개발이 꼬이면 릴리스도 꼬인다. 릴리스가 꼬이면 일정이 뒤엉킨다.

이제는 main, dev/mainline, feat/* 구조가 머리에 꽉 박혔다. 뭐든 익숙해지면 쉽다. 내일은 동료한테도 이 흐름을 같이 정리해보자고 제안해야겠다.

git merge

오늘 이렇게 feat → dev/mainline → main으로 이어지는 Git 브랜치 전략을 다시 정리해보니 확실히 머릿속이 정리된다. 이 구조의 핵심은 각 브랜치가 어떤 역할을 하는지 명확하게 나눠서 운영하는 것이다. 어떤 브랜치에 어떤 코드 상태가 있는지 쉽게 파악되고, 팀원끼리 실수 없이 협업하기도 쉽다.

프로덕션 배포용 안정 브랜치(main)와 개발 통합 브랜치(dev)를 나눠서 쓰면, 검증 안 된 코드가 실수로 운영에 포함되는 것도 막을 수 있고, 문제가 생겼을 땐 main에서 바로 핫픽스도 할 수 있다. 이건 진짜 큰 장점이다.

물론 모든 팀에 똑같은 전략이 맞진 않을 거다. 소규모 팀이나 배포를 자주 하는 팀은 GitHub Flow나 트렁크 기반 개발도 더 적합할 수 있고. 중요한 건 우리 팀의 규모와 방식에 맞는 전략을 합의해서 꾸준히 지키는 것.

이 브랜치 전략이 앞으로 우리 팀의 작업 흐름을 더 정돈되게 만들어줬으면 좋겠다. 그리고 나 자신도 더 실수 없이, 효율적으로 Git을 다룰 수 있길.

 

Git 전략도 결국은 협업을 위한 약속. 이 일기를 공유하면 내일 팀의 Git 문화가 한 단계 성장하길 기대하며 😊