Git Flow가 가진 문제점과 솔루션

GitLab Flow

Jake

Full-Stack Engineer

2020년 9월 22일 · 약 10분

때때로, 좋은 게 너무 많아서 문제일 때도 있습니다. 소프트웨어 개발 워크플로우로 잘 알려진 Git Flow의 경우가 그렇습니다. Git Flow는 좋은 기능이 많지만, 역효과가 있을 때도 있습니다.

GitLab은 복잡성을 줄이고 개발 프로세스의 효율을 높이고자 GitLab Flow를 개발했습니다. GitLab Flow는 Git 워크플로우에 이슈트래킹을 연동함으로써 프로세스를 단순화하고 혼란을 줄입니다. 지금부터 Git Flow의 문제점과 이를 해결하는 GitLab Flow를 알아봅니다.

Git Flow의 문제점

GitLab Flow가 해결하고자 하는 문제점을 살펴보면 GitLab Flow가 어떻게 동작하는지 이해하기 쉽습니다. Git Flow에서는 두 가지의 주요 포인트가 있는데, 두 가지 모두 불필요한 브랜치간의 변환 작업을 수반합니다.

Git Flow는 개발자가 마스터 브랜치보다 개발용 브랜치를 사용하도록 강제합니다. 그런데 많은 도구는 마스터 브랜치에 사용하는 것을 기본 (Default) 으로 하고 있어서 브랜치 간 변환 작업의 양이 아주 많아지게 됩니다. 또 다른 비효율은 hotfix를 브랜치에 업데이트하는 작업인데, 이 작업은 지속 배포 (Continuous Delivery) 구조를 갖춘 대부분의 조직들에게는 필요 없는 작업입니다.

GitLab은 위 문제를 간단하면서도 포괄적으로 해결하기 위해 GitLab Flow를 만들었습니다.

GitLab Flow : 단순화된 브랜치 전략

GitLab Flow는 기능 중심 개발 (feature-driven)과 이슈 트래킹 시스템에 연계되는 기능 개발 브랜치 (feature branch)를 합친 개념입니다. GitLab Flow는 Git 워크플로우와 이슈 트래킹 시스템을 연동 및 통합시킴으로써 단순하고 투명하며 효율적인 Git 작업을 가능하게 합니다.

GitLab Flow는 코드와 이슈 트래커의 연계를 더욱더 투명하게 보여줍니다. 이슈 트래킹 시스템으로부터 모든 코드 베이스 변화 업무가 시작됩니다. 코딩을 끝냈거나 코드에 대해 협의하고 싶다면 머지 리퀘스트 (merge request)를 열 수 있습니다. 코드가 준비되었다면 승인권자는 코드를 마스터 브랜치에 반영되도록 승인하고, 이는 추후 쉽게 확인할 수 있도록 기록이 남습니다. GitLab Flow를 사용함으로써 개발자 및 직원들은 마스터 브랜치를 운영용 브랜치에 반영시킴으로써 (merge) 새로운 버전의 코드를 배포할 수 있으며 어떤 코드가 운영 상태에 있는지 쉽게 구분할 수 있습니다. GitLab Flow에서는 커밋은 다운 스트림으로만 동작하므로 모든 환경에서 테스트 되었음을 알 수 있습니다.

GitLab Flow는 Git Flow에서 자주 있는 릴리즈, 태깅, 머지 (merge) 측면에서의 비효율성을 제거합니다.

GitLab Flow를 간단히 소개하면 아래와 같습니다.

모든 기능과 변경 점은 마스터 브랜치로 향함
‘운영용’ 브랜치와 ‘안정화된' 브랜치에는 이를 허용함
버그 픽스, 핫 픽스 패치들은 우선 마스터 브랜치에서 선별적으로 수용됨

소프트웨어 개발 단계를 10개로 나눠보기

GitLab Flow는 아이디어 단계에서부터 운영단계까지 모두가 정보를 공유하고 효율적으로 일할 방법을 제공합니다. GitLab 은 소프트웨어가 운영단계로 가려면 꼭 거처야 할 개발 프로세스의 10개 단계를 구분한 바 있습니다. GitLab Flow는 최대한의 가시성을 확보하면서도 위 10개 단계를 잊지 않고 거칠 수 있도록 도와줍니다.

크게 보아 GitLab Flow는 다음 3개 영역으로 나뉩니다.

기능 브랜치 (feature branch)
운영 브랜치 (production branch)
릴리즈 브랜치 (release branch)

기능 브랜치는 실질적인 개발 작업이 일어나는 공간입니다. 개발자는 기능을 개발하거나 버그 픽스를 만들거나 하는 일들을 마스터 브랜치가 아니라 기능 브랜치에서 수행하게 됩니다. 작업이 완료되면, 개발자는 머지 리퀘스트 (merge request)를 생성하여 작업물을 마스터 브랜치로 반영 (merge) 합니다.

운영 브랜치는 기본적으로 단일 구조입니다. 개별 브랜치들이 각각 운영되기보다는 하나의 브랜치가 운영상태에서 오랫동안 운영되는 형태입니다. 세부적인 변화를 추적하기 위해서 각각의 배포 버전에 대해 태깅을 하는 것은 가능합니다.

마지막 브랜치 종류인 릴리즈 브랜치는 만약 여러분들께서 여러분의 소프트웨어를 고객들을 위해 릴리즈한다면 매우 중요합니다. 매번 새로운 릴리즈가 있을 때마다, 여러분들은 마스터 브랜치로부터 ‘안정화' 브랜치를 만들고 그곳에 태깅할 것입니다. 만약 여러분들께서 패치를 릴리즈하는 작업을 하신다면, 필수 불가결한 (critical) 버그 픽스를 선별 선택하시기를, 그리고 ‘안정화' 브랜치에 직접 커밋하지 마시기를 권합니다.

기본적으로 따라야 할 규칙

GitLab Flow 전체를 따르고 싶지 않으시다면 다음의 규칙은 숙지하시는 것이 좋습니다. GitLab 의 CEO인 Sid Sijbrandij는 최대한의 효율을 위해 지켜야 할 11가지 규칙을 말씀드린 바 있습니다. 본 규칙들을 전부 읽어보신다면 가장 좋겠지만, CI 환경을 포함하여 테스트의 중요성을 위해 본 페이지에 몇 가지를 남깁니다.

모든 커밋을 테스트하십시오 : 모든 사항이 마스터 브랜치로 반영 (merge) 되기를 기다리지 않는 것이 좋습니다. 문제점을 최대한 빨리 찾아내기 위해서는 커밋되는 순간 테스트하는 것이 좋습니다.
모든 종류의 테스트를 거치십시오 : 병렬 테스트라고 할지라도 모든 종류의 테스트를 하는 것이 좋습니다.
코드 리뷰 후에는 마스터 브랜치로 merge 하십시오 : 기다릴 이유가 있나요? “한꺼번에 테스트하지 마시고, 매 순간 테스트하시는 것을 권합니다. 여러분들께서 직접 문제점을 찾아낼 가능성이 크고, 동료들의 도움을 받을 수도 있습니다.”라고 Sid는 말합니다.