Git 브랜치 전략

곽민서·2025년 7월 28일

여러 개발자가 하나의 저장소에서 작업을 할 때, 협업을 좀 더 효과적으로 하기 위해 git branch에 대한 규칙을 정하고 저장소를 잘 활용하기 위한 workflow를 정의하는 것을 git 브랜치 전략이라고 한다.

Git 브랜치 전략

git 브랜치 전략에는 대표적으로 Git Flow, GitHub Flow, Trunk-Based Development가 있다.

Git Flow

Git Flow는 가장 전통적으로 많이 사용되는 방식으로, Git Flow에서 기능 개발은 feature 브랜치에서 이루어지고, 완료된 후 develop 브랜치에 병합된다. 릴리스를 준비할 때는 release 브랜치를 따로 만들어 최종 검증을 거친 뒤, 프로덕션 코드를 관리하는 main에 병합하게 된다. 만약 긴급한 수정 사항이 발생하면 hotfix 브랜치를 만들어서 신속히 배포하고, 수정 사항을 develop 에도 반영한다.

[출처] https://devocean.sk.com/blog/techBoardDetail.do?ID=165571&boardType=techBlog

Git Flow를 이용하면 대규모 프로젝트에서 체계적이고 안정적인 관리가 가능하지만, 브랜치가 많아짐에 따라 복잡도가 올라간다는 단점이 존재한다.

브랜치 역할

main/master : 제품 출시 버전을 관리하는 메인 브랜치
develop : 다음 출시 버전을 위해 개발하는 브랜치
feature : 새로운 기능을 개발하는 브랜치
release : 다음 출시 버전을 준비하는 브랜치
hotfix : 출시된 제품의 버그를 고치기 위한 브랜치

개발 흐름

신규 기능 개발을 위해 develop 브랜치를 기준으로 한 feature 브랜치를 따서 작업 진행
작업이 완료된 feature 브랜치는 develop 브랜치로 Merge(병합)

일반적으로 Pull Request를 통해 작업 내용을 리뷰받은 후 해당 PR을 Merge하는 방식으로 진행된다.
다음 출시 버전을 위해 개발중인 develop 브랜치에서 release 브랜치를 따서 배포를 위한 준비 시작
일정한 주기로 main 혹은 master 브랜치로 Merge하여 제품 출시
상용 배포 이후, release 브랜치에서 발견되지 못한 버그들은 hotfix 브랜치에 바로 반영

[출처] https://blog.3o3.co.kr/231101-insight/

GitHub Flow

GitHub Flow는 Git Flow보다 단순한 구조를 가지고 있다. 모든 변경 사항은 main 브랜치 기준으로 이루어지는데, 새로운 기능을 개발할 때 feature 브랜치를 생성한 뒤 작업이 끝나면 코드 리뷰를 받고 바로 main 에 병합한다. 이 방식은 간소화된 프로세스를 가지고 있기 때문에 짧은 주기의 배포 환경에서 특히 유용하다. 하지만 릴리스와 QA를 위한 별도의 브랜치가 없기 때문에, 안정성 관리가 중요한 프로젝트에는 다소 부담스러울 수 있다.

쉽게 말해, main 브랜치와 feature 브랜치 두 개 만으로 운영하여 간단하고 빠르게 배포할 수 있는 전략이다.

브랜치 역할

main/master : base 브랜치
feature : main/master에 기능을 추가하기 위한 브랜치

개발 흐름

main/master 브랜치는 배포를 위한 소스코드를 관리하는 브랜치. 신규 기능 개발이 필요할 때, feature 브랜치를 따서 작업 진행
테스크가 완료되면, Pull Request를 생성하여 리뷰를 요청 (이때 타겟은 main/master 브랜치)
리뷰가 완료되고, 피드백이 모두 반영되면 해당 feature 브랜치를 main/master 브랜치로 Merge

[출처] https://blog.cawcaw253.com/posts/git-workflow/

Trunk-Based Development

Trunk-Based Development는 main/master 혹은 trunk브랜치 하나만 운용하는 방식이다. 작업을 main/master 브랜치에 직접 커밋하거나, feature 브랜치를 만들고 며칠 내에 빠르게 병합한다. 병합 주기가 짧아 코드 충돌 가능성이 적다는 장점이 있다. 한편, 철저한 자동화 환경이 뒷받침되어야 한다는 단점이 있다.

[출처] https://www.travis-ci.com/blog/explaining-trunk-based-development/

어떤 전략을 사용해야할까?🤔

프로젝트 상황에 맞는 전략을 선택하는 게 중요하다.

Git Flow는 릴리스 주기가 길고 QA가 중요한 프로젝트에서 사용하기 적합하다. 예를 들어, 금융 서비스처럼 안정성과 품질이 중요한 프로젝트에서는 Git Flow가 더 적합할 것이다.

반면, GitHub Flow는 자주 배포가 이루어지고 변경 사항을 빠르게 반영해야 하는 스타트업과 유사한 환경에서 유리할 것이다.
다양한 관점에서 Git Flow와 GitHub Flow를 비교해보면 다음과 같다.

	Git Flow	GitHub Flow
브랜치 수	다양한 종류의 브랜치 사용	단일 브랜치(`main/master`) 사용
배포 방식	`release`와 `hotfix`브랜치를 통한 명확한 배포 절차	단순하며 지속적인 배포 강조, `main/master` 브랜치에서 배포를 수행
복잡성	복잡한 프로젝트나 대규모 팀에서 사용하기 좋음. 하지만 작은 팀이나 개인 프로젝트에 적용하기에는 많은 브랜치와 과정이 불필요하고 부담스러울 수 있음	단순하며 빠른 개발 및 배포 가능