Git Flow를 소개하는 이유

안녕하세요. 에임스의 기술개발팀 소속 소프트웨어 백엔드 개발자인 김영한입니다. 현재 에임스는 Git, Docker, Kubernetes, Slack, Jira, Confluence 등의 협업 툴을 지속해서 도입하며 개발 문화를 정립해가는 과정에 있습니다. 그중 제가 소개할 것은 Git, 그중에서도 브랜칭 모델인 Git-Flow입니다.

제가 Git-Flow를 소개하려고 하는 데는 두 가지 이유가 있는데,

첫 번째로 현재 저희 회사의 규모가 커지며 지속해서 개발자를 채용하고 있기 때문입니다. 회사의 규모가 커지며 개발 중인 프로젝트에 더 많은 비즈니스 니즈가 생겼고 이에 따라 한 프로젝트에 커밋하는 인원 또한 늘어나게 되었습니다. 따라서, 한 브랜치(예를 들면 master)에만 여러 인원이 커밋하여 소스가 충돌 또는 누락되는 불상사를 막고자 브랜칭 모델인 Git-Flow를 소개하게 됐습니다.

두 번째 이유는 브랜칭 모델을 정립하는 것이 보다 CI, CD를 안정적으로 진행하는 데 기초가 된다고 생각했기 때문입니다. 에임스는 올해 전기 스쿠터(AIO)와 호환되는 배터리 스테이션, 푸드 테크 시스템(Ondal)을 비롯한 여러 프로젝트의 출시를 앞두고 있습니다. 사용자가 많아질수록 비즈니스 니즈를 폭발적으로 증가할 것이고, 에임스는 이에 신속하게 대응할 수 있는 안정적인 CI, CD 환경을 구축하려 노력하고 있습니다. 이를 위해서는 개발 중인 브랜치와 배포할 브랜치를 명확히 구분해야 할 필요성을 느꼈고 브랜칭 모델을 찾던 중 가장 많이 사용하는 방법론 중 하나인 Git-Flow를 찾아 소개하려고 합니다.

이제 Git-Flow 전략에 대해 알아보겠습니다.

Git Flow 전략 살펴보기

Git-Flow는 Vincent Driessen이라는 분의 블로그로 널리 퍼지게 된 브랜칭 모델로 위에서 말씀드린 것처럼 가장 많이 사용하는 방법론 중 하나입니다. 살펴보기에 앞서 주의할 점은 Git-flow는 어떤 기능이 아니고 개발자 간에 정한 방법론이며, Vincent 자신도 말했듯이 완벽한 방법론이 아니라는 것입니다. 따라서, 개발 환경에 따라 이 모델을 수정하고 변형하여 사용하는 것이 더 효율적입니다.

Git-Flow에는 5가지 종류의 브랜치가 존재합니다. 그중 master와 develop(dev) 브랜치는 항상 유지되는 메인 브랜치이며, feature, release, hotfix는 일정 기간만 유지되는 보조 브랜치입니다.

master : 제품으로 출시될 수 있는 브랜치 develop(dev) : 다음 출시 버전을 개발하는 브랜치 feature : 특정 기능을 개발하는 브랜치 release : 이번 출시 버전을 준비하는 브랜치 hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

위 그림의 개발 흐름을 살펴보겠습니다. 일단 master 브랜치와 그로부터 파생된 develop 브랜치를 만듭니다. develop 브랜치에서는 수시로 개발하며 커밋할 수 있습니다. 사실 간단한 프로젝트(참여 인원이 적은 프로젝트)라면 master와 develop 브랜치만으로도 충분하다고 생각합니다. develop 브랜치에 개발한 소스를 수시로 커밋하고 master로 merge하면 되기 때문입니다.

그러나, 프로젝트가 복잡해지고 참여 인원이 많아질수록 위에서 설명한 보조 브랜치들이 필요하게 됩니다. 특정 기능을 추가할 경우 기능별로 develop 브랜치에서 feature 브랜치를 생성합니다. (예를 들어, feature_auth, feature_payment, …) 즉, feature 브랜치는 언제나 develop 브랜치에서 파생됩니다. 기능 추가가 완료되면 feature 브랜치를 develop 브랜치로 merge 합니다. 이번 버전에 포함될 여러 feature 브랜치들이 develop 브랜치에 모두 merge 되었다면 QA를 하기 위해 develop 브랜치에서 release 브랜치를 생성합니다. QA에서 발견된 오류는 release 브랜치에서 수정합니다. QA 후에는 release 브랜치를 master 와 develop 브랜치로 merge 합니다. 마지막으로 출시된 master 브랜치에서 버전 태그를 추가합니다.

Git Flow 전략의 장점과 단점

Git-Flow 모델에 대해 살펴본 후, 이를 적용한 많은 개인과 기업들의 후기도 검색해보며 Git-Flow 모델을 적용해봤습니다. 이후 이 모델의 몇가지 장점과 단점을 확인할 수 있었습니다.

장점 1. branch와 merge의 장점을 최대한 활용할 수 있다.

예를 들어 인증(auth) 기능과 결제(pay) 기능을 각각 다른 개발자가 개발하고 있으며 두 개발자가 수정해야 하는 소스가 겹친다고 가정해봅시다. master라는 하나의 브랜치에 각 개발자들이 커밋을 한다고 가정하면 git log는 다음과 같을 것입니다. (아래의 auth-1, pay-1 등은 커밋 아이디를 편하게 예로 든 것입니다.)

auth-1, pay-1, auth-2, auth-3, pay-2, auth-4, ...

두 개발자가 수정해야 하는 소스가 겹치므로 개발자들은 한 기능의 작은 단위를 커밋할 때마다 소스가 충돌하는지 확인해야 합니다. 또한 한 기능 자체를 롤백시켜야 할 경우 개별 커밋을 일일이 롤백해야 하는 상황이 벌어질 수도 있습니다.

브랜칭 모델을 통해 branch와 merge의 장점을 활용한다면 이러한 문제를 해결할 수 있습니다. 가령, 개발자들은 feature-auth, feature-pay 와 같은 브랜치에서 각각 작업한 후 merge의 여러 옵션(-ff, –no-ff 등)을 활용하여 충돌에 대응할 수 있습니다. 또한 브랜치를 merge하기 전에 한 기능 자체를 롤백할 경우, 브랜치 자체를 삭제하면 됩니다.

장점 2. master 브랜치의 tag를 기준으로 배포하기 때문에 보다 명확한 배포가 가능하다.

master의 tag를 명확한 기준으로 삼아 배포할 수 있습니다. 예를 들어 kubernetes로 배포할 경우, tag를 기준으로 docker image를 만든 뒤 docker hub에 push합니다. 이후 kubernetes deployment object의 image tag를 수정하여 해당 tag를 배포할 수 있습니다.

단점 1. 많은 브랜치 때문에 여러 비용이 발생한다.

Git-Flow를 그대로 따라 브랜칭 모델을 만들었을 때 5개 이상의 브랜치를 만들게 됩니다. 이에 따라 각 브랜치로 switch, 만약 Upstream Repository와 각 개발자의 Remote Repository를 나눠놨을 경우 발생하는 Pull Request, 코드 오너가 Pull Request를 승인하며 진행하는 여러 번의 코드 리뷰.. 이렇듯 지나치게 브랜치가 많을 경우 그에 따른 비용도 증가합니다.

단점 2. 장애가 발생할 경우 master 브랜치의 tag를 기준으로 롤백해야 한다.

1.1.2 라는 tag에 10개의 커밋이 포함되어 있다고 가정해봅시다. 이 때 10개의 커밋 중 하나의 커밋이 장애를 발생시킬 때 어떻게 해결할 수 있을까요? tag 기반으로 배포하고 있기 때문에 한 tag 전체를 롤백하여 1.1.1 tag로 돌아갈 수 밖에 없습니다. tag 기반의 배포는 명확한 기준을 제공하지만 하루에 수십, 수백 회의 배포를 진행해야 하는 상황에 대해서는 이렇듯 유연하게 대처하지 못할 수 있습니다.

결론

Vincent Driessen은 2010년에 작성한 자신의 글에 이런 내용을 추가했습니다.

(전략) To conclude, always remember that panaceas don't exist. Consider your own context. Don't be hating. Decide for yourself.

전략한 내용을 덧붙여 말하자면, Git-Flow는 자신이 10년 전에 고안한 방법론이며 상황에 따라 GitHub flow 와 같은 보다 심플한 모델을 사용할 것을 권고하고 있습니다.

물론 Git-Flow는 여전히 널리 쓰이고 있는 브랜칭 모델이며, Git-Flow를 쓰지 않더라도 브랜칭 모델의 좋은 예시 중 하나라고 생각합니다. 하지만 Vincent 자신의 말처럼 Git-Flow를 만병통치약처럼 사용하기보다는 개발 상황을 고려하며 Git-Flow를 수정하여 사용하거나, 다른 브랜칭 모델을 고려하는 것도 좋을 거 같습니다.

다음 작성자는 저희 회사의 또다른 소프트웨어 백엔드 개발자인 이신 조창후 선임 연구원입니다.