[Git] Gitflow

 

Git Logo

 

협업을 하다보면 Git 은 필수인 시대가 되었습니다. Git 을 사용하다보면 하나의 규칙으로 사용하는데 필요성을 느낍니다. 이러한 개발자들을 위해 Gitflow, Github flow, Gitlab flow 등의 Workflow 전략들이 제시되었습니다.

Gitflow

 

 

Gitflow 는 가장 최초로 제안된, 그리고 가장 유명한 Git Workflow입니다. Gitflow 는 브랜치 전략에 있어서 다른 Workflow 보다 엄격합니다. 때문에 이 Workflow 는 대규모의 프로젝트를 관리하는데 적합한 것으로 평가 받고 있습니다. 또 Gitflow 는 계획적인 릴리즈 계획을 갖고 있는 프로젝트에 유용하게 사용할 수 있습니다.

 

Gitflow 의 브랜치 전략

Gitflow 의 작업 방식을 이해하려면 Gitflow 의 브랜치 전략에 대해 이해해야 합니다. Gitflow는 5가지의 브랜치를 규정하고 있습니다.

1. Master
2. Develop
3. Feature
4. Release
5. Hotfix

Gitflow Structure

# Master

Release 를 할 때 사용하는 최종 단계의 Main Branch 입니다. Master Branch 는 Release 기록을 담고 있습니다. 그리고 Tag 를 통해 Versioning 을 하게 됩니다. 최근에 Master 가 논란이 되어 Main Branch 로 변경하고 있는 추세입니다.

# Develop

다음 Release Version 개발을 진행하는 Branch 입니다. 어떤 기능의 구현이 필요해지면 Develop Branch 에서 Feature Branch 를 만들어서 개발을 진행하며, 개발이 완료된 기능은 다시 Develop Branch 로 병합합니다.

# Feature

Develop Branch 에서 기능 구현을 이유로 Branch 를 만들 때 사용하고, Feature Branch 를 만드는 기준은 한 기능 단위 입니다.

# Release

Develop Branch 에서 파생되는 Branch 입니다. 현재 코드가 Main Branch 로 병합될 수 있는지 테스트하고 테스트 과정에서 발생한 버그를 고치는 역할을 담당하고 있습니다. 이상이 없다면 Release Branch 는 Main(Master) Branch 로 병합됩니다.

# Hotfix

검수를 진행했음에도 Release 된 Main Branch 에서 Bug 가 발견될 수 있습니다. 이 때 Main Branch 에서 Hotfix Branch 를 만들어 버그를 수정합니다.  Debug 가 완료되었다면 Main Branch 와 Develop Branch 에 병합해주고 Branch 를 닫습니다.

# 비판

이러한 Branch 전략은 엄격하게 각각의 브랜치의 역할을 규정하기에 계획적인 Release 를 스케줄링하는 대규모 프로젝트에 적합합니다. 일각에서는 이런 Gitflow 방식이 대다수의 소프트웨어 개발 프로젝트에는 불필요한 절차를 준수하도록 해, 생산성을 떨어뜨린다는 비판이 일기도 했습니다. 이러한 불만의 목소리를 등에 업고 제시된 방식이 Github flow 와 Gitlab flow 입니다.