글을 쓰다 보면 하나의 주제를 오래 붙들고 있는 나를 발견한다.
완전히 이해하고 넘어가고 싶은 욕심 때문일 것이다.
시간이 오래 걸리지만, 그만큼 깊게 고민한 순간은 분명히 남는다.
그래도 이해가 안 가서 고민하고 생각하고 그러다 보면
머릿속에서 문제를 깨닫고 번뜩일 때가 있는데
그거만큼 짜릿한 게 없다.
조금 말이 많았는데 바로 잡고 바로 가보겠다.
그럼 Leshgo
1. Git Flow
Git Flow는 브랜치를 역할별로 분리해서 협업을 안정적으로 만드는 전략이다.
핵심은 "브랜치 전략"
목표는 "협업의 안정성"으로 잡고 넘어간다.
2. 왜 이런 전략이 필요한가
시작하기에 앞서,
해본 협업 프로젝트가 아직 많지는 않지만
해보면서 계속 떠오르던 생각이 하나 있다.
'내가 뭔가 잘못 건드려서, 다 날아가는 거 아니겠지?'
사실 이 고민은 "나 혼자만" 쓰는 브랜치에선 아무런 걱정도 안된다.
근데 이제 작업물을 merge하는 과정에서 항상 조심스러워진다.
그리고 다음은 사람들이 느끼는 협업에서 제일 무서운 것들이다.
- 배포 직전 코드 깨짐
- 기능 개발하다가 버그 수정 들어감
- 여러 사람이 동시에 작업해서 일어나는 충돌 지옥
즉, 모든 작업이 한 줄(main)에 몰리는 것이 문제다.
사실 나는 feature 브랜치, dev 브랜치, main 브랜치 다 나눠서 작업했는데도 불구하고
main 혹은 dev, 팀원들과 직접 연결되어 있는 브랜치에 작업을 할 때면 그렇게 겁이 막 난다.
아무튼 그래서 이 Git Flow는 우리에게 번뜩이는 아이디어를 하나 심어준다.
"작업 종류별로 공간을 나눠라."
3. Git Flow의 기본 구조
핵심 브랜치
main
- 실제로 배포되는 안정 버전
- 항상 깨지면 안됨
develop
- 다음 배포를 준비하는 통합 브랜치
- 기능들이 모이는 곳
여기까지가 뼈대를 이룬다.
그 위에 올라가는 작업 브랜치들
feature/*
- 새로운 기능 개발
- develop에서 복제
- develop으로 merge
release/*
- 배포 준비 단계
- develop에서 복제
- 테스트 & 버그 수정
- main과 develop 모두에 merge
hotfix/*
- 긴급 버그 수정
- main에서 복제
- 수정 후 main + develop에 merge
위 그림과 같은 흐름으로 진행된다.
여기서의 핵심은:
- 기능은 develop으로 모인다.
- 배포는 release를 거친다.
- 긴급수정은 main에서 바로 고친다.
4. 협업의 구조화
Git Flow는 이렇게 선언하는 전략이다:
| 작업 종류 | 브랜치 | 설명 |
|---|---|---|
| 기능 개발 | feature/* | 새로운 기능을 개발하는 브랜치. develop에서 생성 후 develop으로 병합 |
| 통합 개발 | develop | 여러 feature가 모이는 통합 브랜치. 다음 배포를 준비하는 공간 |
| 배포 준비 | release/* | 배포 직전 안정화 작업(버그 수정, 테스트)을 위한 브랜치 |
| 긴급 수정 | hotfix/* | 운영 중인 main에서 발생한 긴급 버그를 수정하는 브랜치 |
| 실제 서비스 | main | 실제로 배포되는 안정 버전 브랜치 |
작업의 "성격"에 따라 공간을 분리하면서 구조화된다.
5. Git Flow의 현실
구조화가 잘 되어있는 Git Flow는 사실 이런 단점도 갖고 있다:
- 브랜치 많음
- 복잡함
- CI/CD 환경에선 과함
이런 단점으로 빠른 배포를 반복하는 팀에서는
더 단순한 전략이 선호되기 때문에 GitHub Flow를 더 애용하게 된다.
그래도 규모가 있고, 명확한 릴리즈 주기가 있는 팀에서는
여전히 의미 있게 작용한다.
6. 핵심 정리
Git Flow는 브랜치를 단순히 나누는 방법이 아니라,
협업 상황에서 발생할 수 있는 혼선을 줄이기 위해
작업의 성격에 따라 공간을 분리하는 전략이다.
main은 항상 배포 가능한 안정 상태를 유지한다.develop은 다음 배포를 준비하는 통합 공간이다.feature는 기능 개발을 위한 독립 공간이다.release는 배포 직전 안정화를 담당한다.hotfix는 운영 중 긴급 문제를 빠르게 해결한다.
즉, Git Flow의 핵심은
"모든 작업을 한 줄에서 처리하지 않는다"는 원칙에 있다.
브랜치를 역할별로 나누는 순간,
협업은 감각이 아니라 구조 위에서 동작하게 된다.
