Git Flow 전략을 선택한 이유와 main 브랜치의 역할

프로젝트를 진행하면서 브랜치를 어떻게 관리할지가 늘 고민이었다. 여러 기능이 동시에 개발되고 QA와 배포가 구분되는 환경에서는 명확한 프로세스가 필요하다고 느꼈다. 그래서 나는 Git Flow 전략을 선택했다.

 

💡 Git Flow를 선택한 이유

Git Flow는 main, develop, feature, release, hotfix 브랜치로 구성되어 있으며, 각 브랜치가 고유한 역할을 가지고 있다. 이 구조 덕분에 병렬로 여러 버전을 관리할 수 있고, QA 과정에도 최적화되어 있기 때문에 해당 전략을 선택하게 되었다.

 

 

✅ main 브랜치의 역할을 새롭게 이해하다

처음에는 main 브랜치를 단순히 “기본 브랜치” 정도로만 생각했다. 그래서 프로젝트 초반에는 main을 거의 사용하지 않았다. 하지만 Git Flow를 깊게 이해하면서 main의 역할을 명확히 알게 되었다. main 브랜치는 실제 운영(Production) 버전을 나타내는 브랜치다.

즉, 실제 서비스에 배포된 코드만 main에 존재해야 한다. 항상 안정적이고 배포 가능한 상태를 유지해야 하는 브랜치다.

릴리스가 완료되면 QA를 마친 release 브랜치를 main에 병합하고, 그 시점에 태그(v1.0.0, v1.1.0 등)를 달아 배포 이력을 관리한다. 이렇게 하면 main 브랜치가 항상 최신의 운영 버전을 대표하게 된다.

 

⚙️ release 브랜치와 main 브랜치의 차이

처음에는 release가 운영 버전이라고 생각했지만, 사실 release는 배포 전 QA용 브랜치이고 main이 배포 후 실제 운영 버전이다. 아래 예시처럼, 사용하면 된다.

(feature/login)  →  develop
                       ↓
                 release/1.4.0   ← QA 및 버그 수정
                       ↓
                     main  ← 운영 배포 (tag: v1.4.0)

 

Git Flow를 사용하면서 단순히 브랜치를 나누는 것을 넘어서 각 브랜치가 왜 존재하는지, 어떤 책임을 가지는지를 이해하는 것이 중요하다는 걸 느꼈다. 특히 main 브랜치는 단순한 기본 브랜치가 아니라 항상 배포 가능한 코드의 기준점이자 프로젝트의 품질과 신뢰성을 지켜주는 핵심 브랜치다. 이제는 main 브랜치를 중심으로 릴리스 프로세스를 관리하며 안정적인 배포 환경을 유지해야겠다.