브랜치 전략

브랜치 전략은 여러 사람이 함께 코드를 고칠 때 브랜치를 언제 만들고 언제 합칠지를 미리 정해 두는 규칙입니다. 이 규칙이 없으면 각자 편한 대로 브랜치를 쓰다가 서로의 작업을 덮어쓰게 됩니다. 팀은 이 규칙을 정해 두고 모두 같은 방식으로 브랜치를 씁니다.

쉽고 빠른 이해

브랜치 전략은 브랜치를 쓰는 방식에 대한 팀의 약속입니다. 언제 새 브랜치를 만들지, 언제 합칠지, 어떤 브랜치를 배포에 쓸지를 정합니다.

이 약속이 없으면 브랜치가 오래 방치되다 나중에 합칠 때 충돌이 커집니다. 지금 어떤 브랜치가 배포해도 되는 상태인지도 알기 어려워집니다.

혼자 개발하거나 팀원이 같은 코드를 동시에 고칠 일이 드물면 이 규칙을 엄격히 정하지 않아도 됩니다. 문제가 커지는 것은 여러 사람이 같은 코드를 자주 함께 고치기 시작할 때부터입니다.

정하는 것은 크게 셋입니다.

1. 브랜치를 얼마나 오래 살려 둘지
2. 브랜치를 합치는 순서와 시점
3. 배포에 쓰는 브랜치와 이름 규칙

대가도 있습니다. 브랜치를 짧게 유지하는 쪽은 자주 합쳐야 해서 자동 테스트 같은 안전장치가 더 필요합니다. 브랜치를 길게 유지하는 쪽은 그런 장치는 덜 필요하지만, 합칠 때 충돌이 커집니다.

상세

이 절은 브랜치 전략이 왜 필요한지, 그리고 흔히 갈리는 두 방향이 무엇을 다르게 고르는지를 봅니다. 하나의 정답이 있는 문제가 아니라 팀 상황에 따라 저울질하는 문제라는 점도 함께 짚습니다.

규칙이 없으면 생기는 문제

여러 사람이 동시에 브랜치를 만들어 작업하면, 그 브랜치를 언제 병합할지를 아무도 정해 두지 않아도 처음에는 별문제가 안 보입니다. 문제는 시간이 지나면서 드러납니다. 한 사람이 브랜치를 몇 주째 붙들고 있으면, 그사이 기준 브랜치(다른 브랜치들이 갈라져 나오고 다시 합쳐지는 대상이 되는 브랜치)는 계속 바뀌어서 나중에 합칠 때 충돌이 쌓입니다.

다른 사람은 기준 브랜치를 지금 배포해도 되는지 확신을 갖기 어려워집니다. 누군가의 미완성 작업이 이미 들어가 있을 수도 있기 때문입니다. 팀이 커질수록 이 문제는 커집니다. 두 명이면 서로 물어보고 넘어가지만, 열 명이 각자 브랜치를 만들면 정해 두지 않은 규칙 하나하나가 사고가 날 여지로 남습니다.

브랜치를 길게 쓰는 쪽과 짧게 쓰는 쪽

이 문제를 푸는 방향은 크게 둘로 갈립니다. 브랜치를 오래 살려 두고 그 안에서 기능을 다 끝낸 뒤에 합치는 쪽과, 브랜치를 하루 안팎으로만 쓰고 자주 합치는 쪽입니다. 어느 쪽을 고르느냐에 따라 다른 것들이 함께 달라집니다.

이 두 방향에는 각각 이름 붙은 흐름이 있습니다. 브랜치를 짧게 쓰는 쪽을 트렁크 기반 개발이라 부릅니다. 다들 하나의 기준 브랜치(메인라인)에 자주 합치고, 아직 안 끝난 기능은 코드는 들어가 있어도 겉으로는 안 보이게 꺼 두는 방식으로 배포합니다.

브랜치를 길게 쓰는 쪽은 기능마다 따로 브랜치를 두고, 그 기능이 다 끝난 뒤에야 기준 브랜치로 합칩니다. 이 흐름을 정리해 이름 붙인 것 중 하나가 Git 플로우이고, 기능 브랜치와 풀 리퀘스트만으로 더 단순하게 다듬은 흐름을 깃허브 플로우라고 부릅니다.

쓰임에 따라 갈리는 브랜치 이름

브랜치 전략은 흐름만 정하지 않습니다. 브랜치마다 무엇을 위한 것인지 이름과 역할도 정합니다. 실무에서 자주 쓰는 이름 셋이 있습니다.

이 이름들은 서로 배타적이지 않습니다. 평소에는 기능 브랜치를 짧게 쓰다가, 배포가 가까워지면 릴리스 브랜치를 잠깐 열어 그 판만 따로 다듬는 팀도 있습니다.

브랜치 하나가 거치는 상태

브랜치 전략이 실제로 정하는 것은 브랜치 하나가 태어나서 끝나기까지 거치는 상태와, 그 사이를 넘어가는 조건입니다.

stateDiagram-v2
    [*] --> 생성됨: 기준 브랜치에서 갈라진다
    생성됨 --> 작업중
    작업중 --> 리뷰중: 풀 리퀘스트를 연다
    리뷰중 --> 작업중: 고칠 것을 돌려받는다
    리뷰중 --> 병합됨: 승인받아 합친다
    리뷰중 --> 폐기됨: 더 필요 없어진다
    병합됨 --> [*]
    폐기됨 --> [*]

전략이 다르면 이 화살표 위의 조건도 달라집니다. 언제 갈라지는지, 리뷰가 얼마나 오래 걸려도 되는지, 무엇을 승인 기준으로 삼는지가 전부 전략이 정하는 몫입니다. 화살표 자체는 바뀌지 않지만, 화살표를 넘어가는 문턱의 높이가 팀마다 다릅니다.

어느 쪽을 고르나

어느 방향이 맞는지는 정답이 아니라 팀 상황에 달려 있습니다. 자동 테스트가 탄탄하고 자주 배포하는 팀은 브랜치를 짧게 쓰는 쪽이 잘 맞습니다. 합칠 때마다 충돌을 빠르게 잡아낼 안전 장치가 있기 때문입니다.

테스트가 부족하거나, 한 번 배포할 때 검증할 것이 많은 팀은 브랜치를 길게 두고 그 안에서 충분히 다듬는 쪽을 고르는 경우가 많습니다. 대신 그 브랜치가 오래 갈수록 나중에 합칠 대가는 커집니다. 두 방향 다 공짜가 아니라, 어디서 비용을 치를지를 미리 고르는 문제입니다.

관련 항목

브랜치를 다루는 Git 동작

브랜치 · 병합 · 리베이스 · HEAD

이 결정을 구현한 대표 흐름

트렁크 기반 개발 · 기능 브랜치 · Git 플로우 · 깃허브 플로우 · 릴리스 브랜치 · 핫픽스 브랜치

전략이 딛고 서는 개발 습관

지속적 통합 · 피처 플래그 · 풀 리퀘스트 · 코드 리뷰

릴리스 파이프라인에서 나란히 서는 개념

릴리스 엔지니어링 · 소스 코드 관리 · 메인라인 · 체리픽 · 버전관리

커밋 규칙과 맞물리는 절차

커밋 메시지 · 커밋에서 배포까지