Git을 다루는 Workflow: Gitflow, Github flow, Gitlab flow

여러 명이서 협업 프로젝트를 진행하다보면 필연적으로 Git을 사용하게 됩니다.

그렇게 Git을 사용하다보면 일관된 방식으로 사용하는 규칙의 필요성을 느끼는 순간이 오는데, 이러한 개발자들을 위해 Gitflow, Github flow, Gitlab flow등의 워크플로우 전략이 제시되었습니다.

이번 글에서는 위 workflow전략 중 주로 Gitflow의 개념에 대해 알아보도록 하겠습니다. 그리고 말미에는 Gitflow의 대안으로 제시된 Github flow와 Gitlab flow에 대해 간략하게 알아보겠습니다.

Gitflow

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

Gitflow의 브랜치 전략

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

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

Master

릴리즈를 할 때 사용하는 최종 단계의 메인 브랜치입니다. Master브랜치는 릴리즈 기록을 담고 있습니다. 태그를 통해 versioning을 하게 됩니다.

Develop

다음 릴리즈 버전 개발을 진행하는 브랜치입니다. 어떤 기능의 구현이 필요해지면 Develop브랜치에서 다시 브랜치를 내어 개발을 진행하며, 개발이 완료된 기능은 다시 Develop브랜치로 병합됩니다.

Feature

Develop브랜치에서 기능 구현을 이유로 브랜치를 낼 때, 이 브랜치가 Feature브랜치입니다. 브랜치를 내는 기준은 한 기능 단위가 되겠습니다.

Release

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

Hotfix

검수를 진행했음에도 릴리즈된 Master브랜치에서 버그가 발견될 수 있습니다. 이때 Master브랜치에서 Hotfix브랜치를 내어 버그를 수정합니다. 디버그가 완료되었다면 Master브랜치와 Develop브랜치에 병합해주고 브랜치를 닫습니다.

비판

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

Github flow

Github flow는 Master브랜치가 릴리즈에 있어서 절대적인 역할을 합니다. Master브랜치는 항상 최신 버전을 유지합니다. 그리고 무조건적으로 stable한 상태를 담보합니다. Develop브랜치가 존재하지 않고 Feature브랜치는 Master브랜치에서 생성되며,병합됩니다. 병합을 할 때는 무조건 pull request를 하여 코드에 대한 검토를 받도록 합니다. Github flow는 CI가 필수적입니다.

Gitlab flow

Gitlab flow는 너무 단순해진 Github flow에 보완하는 내용을 가미하여 제안된 방식입니다. Gitlab에는 Production 브랜치가 있는데, 이는 Gitflow의 Master브랜치역할과 같습니다. Gitlab flow의 Master브랜치는 Production 브랜치로 병합합니다. 이렇게 브랜치전략을 가져갈 때의 이점은 Production브랜치에서 릴리즈된 코드가 항상 프로젝트의 최신버전 상태를 유지해야할 필요가 없다는 것입니다. Gitflow와 Github의 절충안이라는 느낌을 줍니다.

어떤 방식이 더 나은 방식이라고 꼽을 수는 없습니다. 몇 명의 개발자가 참여하는지, 릴리즈 계획은 어떤 방식인지 등등 모든 프로젝트의 상황은 같지 않기 때문입니다. 때문에 팀의 상황을 파악하여 적절한 방식의 워크플로우를 채택하는 것이 팀의 생산성을 높이는 데 중요합니다.