Git 실무 워크플로우 #1 브랜치 전략 — GitHub Flow와 trunk-based

2026년 7월 13일 월요일

6 분 소요

Git 기초 #3 브랜치와 머지에서 브랜치를 만드는 비용이 사실상 0이라는 사실을 확인했고, Git 기초 #6 GitHub와 첫 Pull Request에서 브랜치를 PR로 합류시키는 절차를 실습했습니다. 그런데 팀에 들어가면 곧바로 다음 질문에 부딪힙니다. 브랜치를 어떤 이름으로 어디서 만들고, 어디로 머지하고, 배포는 어느 시점에 하는가? 이 질문에 대한 팀의 합의가 브랜치 전략입니다. 이 시리즈는 Git 기초의 후속으로, 명령어가 아니라 팀에서 Git을 운영하는 방식을 다룹니다.

총 7편으로 구성됩니다.

#1 브랜치 전략 — GitHub Flow와 trunk-based ← 이번 글
#2 rebase vs merge — 결정 기준과 금기
#3 interactive rebase — squash·fixup으로 커밋 정리
#4 충돌 해결 — 충돌의 구조와 mergetool·rerere
#5 PR 운영 — 리뷰 단위·커밋 메시지·draft PR
#6 stash·cherry-pick·bisect — 일상 도구 셋
#7 모노레포와 Git — sparse-checkout·서브모듈·LFS

이번 글은 실무에서 만나게 되는 대표 전략 세 가지, Git Flow, GitHub Flow, trunk-based development의 구조를 차례로 보고, 마지막에 선택 기준을 표로 정리하겠습니다.

전략이 없을 때 벌어지는 일 #

브랜치 전략 없이 각자 브랜치를 만들기 시작하면 며칠 안에 같은 문제가 반복됩니다. 배포하려는 코드에 아직 검증되지 않은 변경이 섞여 있고, 급한 버그 수정을 어디서 갈라내야 할지 아무도 답하지 못하고, 오래 살아남은 브랜치가 main과 크게 벌어져 머지할 때마다 대형 충돌이 납니다.

전략이 답하는 질문은 세 가지로 요약됩니다.

어디서 만드는가 — 새 작업 브랜치의 출발점이 되는 브랜치
어디로 머지하는가 — 작업이 끝난 브랜치의 합류 지점
무엇을 배포하는가 — 프로덕션에 나가는 코드가 있는 브랜치

세 전략은 이 질문에 서로 다르게 답합니다.

Git Flow — 다섯 종류의 브랜치 #

Git Flow는 2010년에 제안된 가장 오래되고 가장 구조화된 전략입니다. 브랜치를 다섯 종류로 나눕니다.

Git Flow의 브랜치 구조

main     ──●─────────────────●────────▶  릴리스마다 태그 (v1.0, v1.1)
            \               /
release      \         ●──●             릴리스 준비, 버그 수정만
              \       /
develop  ──●───●──●──●───●───●──▶       다음 릴리스를 향한 통합 지점
            \     /   \      /
feature      ●──●      ●───●            기능 단위 작업

hotfix: main에서 갈라져 main과 develop 양쪽에 머지

main — 릴리스된 코드만 존재합니다. 커밋마다 버전 태그가 붙습니다.
develop — 다음 릴리스를 향해 기능이 모이는 통합 브랜치입니다.
feature — develop에서 갈라져 develop으로 돌아갑니다.
release — 릴리스 직전 안정화 기간을 위한 브랜치입니다. 버그 수정만 받습니다.
hotfix — 프로덕션 긴급 수정용으로, main에서 갈라져 main과 develop 양쪽에 머지됩니다.

이 구조는 “몇 달에 한 번 버전을 찍어 배포하는 소프트웨어"를 전제로 설계됐습니다. 설치형 제품, 모바일 앱처럼 릴리스가 이벤트인 환경에서는 지금도 잘 맞습니다. 반면 하루에도 몇 번씩 배포하는 웹 서비스에서는 develop과 release가 통과 의례에 가까워지고, 브랜치 관리 비용만 남는 경우가 많습니다. 원작자 스스로도 10년 뒤에 남긴 후기에서 지속 배포하는 웹 서비스라면 더 단순한 흐름을 고려하라고 권했습니다.

GitHub Flow — main과 짧은 브랜치 #

GitHub Flow는 구조를 극단적으로 줄인 전략입니다. 브랜치는 두 종류뿐입니다.

GitHub Flow의 브랜치 구조

main     ──●────────●────────●──▶   항상 배포 가능한 상태 유지
            \      /        /
feature      ●──●      ●──●         작업 단위로 짧게, PR로 합류

규칙도 짧습니다.

main은 언제나 배포 가능한 상태로 유지합니다.
작업은 main에서 갈라낸 이름 있는 브랜치에서 합니다.
PR을 열어 리뷰를 받고, 통과하면 main에 머지합니다.
머지된 main은 곧바로(또는 가능한 한 빨리) 배포합니다.

눈치챘겠지만 Git 기초 #6에서 실습한 브랜치 생성, 푸시, PR, 머지의 사이클이 바로 GitHub Flow입니다. 별도 학습 비용 없이 PR 문화와 그대로 이어지기 때문에, 지속 배포하는 웹 서비스의 사실상 기본값이 됐습니다. develop도 release도 없으므로 “다음 릴리스에 무엇이 들어가는가” 같은 질문은 브랜치가 아니라 PR과 배포 기록이 답합니다.

trunk-based development — main으로 직행 #

trunk-based development는 여기서 한 걸음 더 나아갑니다. 모든 작업을 main(trunk)에 직접 커밋하거나, 브랜치를 만들더라도 하루 이틀 안에 합류시키는 초단기 브랜치만 허용합니다.

trunk-based의 브랜치 구조

main     ──●──●──●──●──●──●──●──▶   전원이 매일 main에 통합
                 \  /
아주 짧은 브랜치   ●●                  수명 1〜2일 이내

핵심 목표는 통합 지연을 없애는 것입니다. 브랜치가 오래 살수록 main과 벌어지고 충돌이 커지는데, 매일 통합하면 충돌이 자잘할 때 해소됩니다. 대신 전제 조건이 무겁습니다.

탄탄한 자동화 테스트와 CI — 사람이 막지 않아도 깨진 코드가 main에 들어오지 못해야 합니다.
feature flag — 완성되지 않은 기능도 main에 머지하되, 코드 안의 스위치로 꺼 둡니다. 배포와 기능 공개를 분리하는 기법으로, 미완성 기능이 main에 있어도 사용자에게는 보이지 않습니다. 켜고 끄는 것은 배포가 아니라 설정입니다.

이 두 가지가 갖춰지지 않은 팀이 형태만 따라 하면, 깨진 main을 전원이 공유하는 최악의 상태가 됩니다. 구글, 메타 같은 대규모 조직이 이 방식을 쓰는 것은 그만한 인프라가 받치고 있기 때문입니다.

노트

GitHub Flow와 trunk-based의 경계는 생각보다 얇습니다. 기능 브랜치의 수명을 하루 이내로 줄이고 feature flag를 도입하면 GitHub Flow는 자연스럽게 trunk-based에 가까워집니다. 두 전략을 대립 관계가 아니라 브랜치 수명의 스펙트럼으로 보는 편이 실무 감각에 맞습니다.

선택 기준 #

세 전략을 판단 축으로 정리합니다.

기준	Git Flow	GitHub Flow	trunk-based
잘 맞는 배포 모델	버전 릴리스(설치형, 모바일)	지속 배포 웹 서비스	하루 여러 번 배포
브랜치 수명	길다(주 단위)	짧다(일 단위)	아주 짧다(1〜2일 이내)
여러 버전 병행 유지보수	강함	약함	약함
전제 조건	릴리스 관리 체계	CI와 리뷰 문화	강한 CI, feature flag
구조 복잡도	높음	낮음	낮음(운영 난도는 높음)

판단이 필요할 때 던질 질문은 두 가지입니다. 첫째, 릴리스가 이벤트인가 일상인가? 버전을 찍어 배포하고 구버전도 유지보수해야 한다면 Git Flow 계열이 여전히 유효합니다. 둘째, 통합을 매일 감당할 CI가 있는가? 있다면 브랜치 수명을 줄이는 방향, 즉 trunk-based 쪽으로 갈수록 이득이 커집니다.

전략은 도구가 아니라 합의입니다 #

대부분의 팀에게 무난한 출발점은 GitHub Flow입니다. 규칙이 적고, PR 리뷰 문화와 자연스럽게 결합하며, 필요해지면 trunk-based 쪽으로 조정할 수 있습니다. 중요한 것은 어떤 전략을 고르든 팀 전체가 같은 규칙을 공유하는 것입니다. 절반은 develop으로, 절반은 main으로 머지하는 팀은 어떤 전략을 골라도 정리되지 않습니다. 전략 문서를 저장소의 CONTRIBUTING 문서에 짧게라도 적어 두면, 새 팀원이 첫 브랜치를 만들기 전에 답을 찾을 수 있습니다.

마무리 #

이번 글의 핵심은 세 가지입니다.

브랜치 전략은 브랜치의 출발점, 합류 지점, 배포 지점에 대한 팀의 합의입니다.
Git Flow는 버전 릴리스 제품에, GitHub Flow는 지속 배포 웹 서비스에, trunk-based는 강한 CI를 갖춘 고빈도 배포 조직에 맞습니다.
무난한 출발점은 GitHub Flow이고, 브랜치 수명을 줄여 갈수록 trunk-based에 가까워집니다.

다음 글인 “Git 실무 워크플로우 #2 rebase vs merge — 결정 기준과 금기"에서는 갈라진 히스토리를 합치는 두 번째 방법인 rebase를 다룹니다. merge와 무엇이 다른지, 그리고 절대 rebase하면 안 되는 상황이 언제인지 확인하겠습니다.