[Git] Git Flow

Git Flow란?

Git Flow는 Git 브랜치를 역할별로 나누어 사용하는 브랜치 전략이다.

단순히 브랜치를 많이 만드는 방식이 아니라, 각 브랜치에 명확한 책임을 부여한다.

대표적인 브랜치는 다음과 같다.

main
develop
feature/*
release/*
hotfix/*

Git Flow는 특히 다음 상황에서 유용하다.

배포 버전을 명확히 관리해야 하는 경우
여러 기능을 동시에 개발하는 경우
운영 중인 버전에 긴급 수정이 필요한 경우
개발 브랜치와 배포 브랜치를 분리하고 싶은 경우

main branch

main 브랜치는 실제 배포 가능한 안정적인 코드를 관리한다.

일반적으로 main에 있는 코드는 언제든 배포 가능해야 한다.

main = production

따라서 개발 중인 코드를 직접 main에 커밋하지 않는다.
대신 검증이 끝난 release나 hotfix만 main으로 병합한다.

develop branch

develop 브랜치는 다음 배포를 준비하는 개발 브랜치이다.

새 기능들은 보통 develop을 기준으로 만들어지고, 다시 develop으로 병합된다.

develop = next release

즉, main이 현재 운영 버전이라면 develop은 다음 운영 버전 후보이다.

feature branch

feature 브랜치는 새로운 기능을 개발할 때 사용한다.

보통 develop에서 분기한다.

git switch develop
git switch -c feature/login

기능 개발이 끝나면 다시 develop으로 병합한다.

git switch develop
git merge feature/login

역할은 다음과 같다.

기능 단위 작업 분리
아직 완성되지 않은 코드가 develop에 바로 들어가는 것 방지
여러 기능을 동시에 개발 가능

기능 브랜치는 짧게 유지하는 것이 좋다.
너무 오래 유지되면 develop과 차이가 커져 conflict 가능성이 높아진다.

release branch

release 브랜치는 배포 준비를 위한 브랜치이다.

기능 개발이 어느 정도 끝나고 배포 후보를 만들 때 develop에서 분기한다.

git switch develop
git switch -c release/1.0.0

release 브랜치에서는 보통 다음 작업을 한다.

버전 번호 수정
문서 정리
작은 버그 수정
배포 전 최종 테스트

새로운 큰 기능은 release 브랜치에서 개발하지 않는다.
release 브랜치는 이미 개발된 기능을 안정화하는 공간이다.

배포 준비가 끝나면 main과 develop 양쪽에 병합한다.

git switch main
git merge release/1.0.0

git switch develop
git merge release/1.0.0

main에 병합한 뒤에는 보통 tag를 만든다.

git tag v1.0.0

hotfix branch

hotfix 브랜치는 운영 중인 버전에 긴급 버그가 발생했을 때 사용한다.

release와 달리 main에서 바로 분기한다.

git switch main
git switch -c hotfix/login-error

수정이 끝나면 main에 병합해서 바로 배포할 수 있다.

git switch main
git merge hotfix/login-error

그리고 같은 수정사항을 develop에도 반영해야 한다.

git switch develop
git merge hotfix/login-error

이 과정을 빼먹으면 다음 배포 때 같은 버그가 다시 나타날 수 있다.

전체 흐름

Git Flow의 일반적인 흐름은 다음과 같다.

main
  ↑
release/1.0.0
  ↑
develop
  ↑
feature/login

기능 개발 흐름:

develop -> feature/* -> develop

배포 흐름:

develop -> release/* -> main
                         -> develop

긴급 수정 흐름:

main -> hotfix/* -> main
                  -> develop

Git Flow 예시

로그인 기능을 개발한다고 하자.

먼저 develop에서 feature 브랜치를 만든다.

git switch develop
git switch -c feature/login

작업 후 커밋한다.

git add .
git commit -m "feat: add login feature"

기능이 끝나면 develop에 병합한다.

git switch develop
git merge feature/login

배포 준비를 위해 release 브랜치를 만든다.

git switch -c release/1.0.0

테스트와 작은 수정을 마치고 main에 병합한다.

git switch main
git merge release/1.0.0
git tag v1.0.0

release에서 수정한 내용이 있다면 develop에도 병합한다.

git switch develop
git merge release/1.0.0

Git Flow의 장점

브랜치 역할이 명확하다

main, develop, feature, release, hotfix의 역할이 분리되어 있다.

따라서 어떤 작업을 어디서 해야 하는지 명확하다.

배포 관리가 쉽다

main은 배포 가능한 코드만 가지고 있으므로 버전 관리가 명확해진다.

release 브랜치를 사용하면 배포 전 안정화 작업도 분리할 수 있다.

긴급 수정 흐름이 분리된다

운영 중인 버그를 고칠 때 develop의 미완성 기능과 섞이지 않고 main 기준으로 바로 수정할 수 있다.

Git Flow의 단점

Git Flow는 구조가 명확하지만 무겁다.

브랜치가 많고, 병합해야 하는 지점도 많다.

작은 프로젝트나 빠르게 배포하는 서비스에서는 오히려 복잡할 수 있다.

예를 들어 하루에도 여러 번 배포하는 팀이라면 Git Flow보다 trunk-based development가 더 단순할 수 있다.

언제 쓰면 좋은가?

Git Flow는 다음 상황에 잘 맞는다.

배포 주기가 길다.
버전 단위 릴리즈가 중요하다.
운영 버전과 개발 버전을 명확히 나눠야 한다.
여러 기능이 동시에 개발된다.
hotfix 흐름이 자주 필요하다.

반대로 다음 상황에서는 과할 수 있다.

개인 프로젝트
작은 규모의 웹 서비스
매우 짧은 배포 주기
main에 자주 병합하고 바로 배포하는 구조

정리

Git Flow는 다음 브랜치를 중심으로 동작한다.

브랜치	역할
`main`	운영 배포 코드
`develop`	다음 배포를 위한 개발 코드
`feature/*`	기능 개발
`release/*`	배포 준비
`hotfix/*`	운영 긴급 수정

Git Flow의 핵심은 브랜치 이름이 아니라 역할 분리이다.

프로젝트 규모, 배포 주기, 협업 방식에 따라 Git Flow가 적절할 수도 있고 과할 수도 있다.
따라서 무조건 적용하기보다, 현재 프로젝트에 필요한 복잡도인지 먼저 판단하는 것이 중요하다.