F-lab 프로젝트(Write-Now) - Git 브랜치 전략

들어가며...

프로젝트 진행에 앞서 준비하는 과정에서 git 브랜치 전략에 대한 얘기를 멘토님과 하게 됐다. 사실 멘토님에게 프로젝트의 브랜치 전략에 대해 잘 설명하지 못했다. 실무를 할 때 브랜치를 나눠서 관리하고 있지만 주로 혼자하다보니 브랜치 전략에 대해 명확히 이해하지 않았고, 때문에 체계적으로 관리하지 못했다. 이번 기회에 브랜치 전략의 종류에 대해 살펴보고 회사에서 사용하는 브랜치 전략이 무엇인지, 프로젝트에서 사용할 브랜치 전략은 무엇이 적합할지 살펴보고자 한다.

브랜치란 무엇인가?

git에서 사용하는 브랜치란 무엇일까? 정확히는 왜 사용하는 것일까? 결론적으로는 개발의 안정성과 생산성을 높이기 위함이다. 브랜치의 사전적 의미는 가지라는 뜻이다. 여러 가지가 모여서 하나의 나무를 이루듯이 여러 브랜치가 모여서 하나의 소스코드를 이룬다. 만약 브랜치가 없다면 어떨지 생각해보자.

 

하나의 소스코드를 가지고 여러 개발자들이 작업을 하고 있다고 가정해보자. 더 단순화해 하나의 클래스에 대해 여러 개발자들이 공동으로 작업하고 있는 상황을 생각해보자. 개발자 A가 클래스의 인스턴스 변수가 필요하지 않다고 생각해 없앴는데 개발자 B가 작업하는 기능에는 해당 인스턴스 변수가 필요하다. 물론 어플리케이션을 구동할 때 컴파일 에러가 발생하겠지만, 이런 상황이 발생하는 것 자체가 개발 생산성을 떨어뜨린다고 할 수 있다. 협업 중인 개발자들이 많다면 문제는 더욱 복잡해질 것이다.

 

또 하나의 소스코드에서 작업하다보면 기능에 오류가 있어 롤백을 해야할 때 여러 커밋이 섞여있기 때문에 어디까지 롤백을 해야할지 히스토리를 파악하기가 어렵다. 결국 하나의 소스코드로 개발하다보면 안정성이 떨어지고 생산성도 떨어지게 된다. 이런 문제를 해결하기 위해 브랜치를 사용하는 것이다. 예를 들어 메인 브랜치는 건드리지 않고 기능별로 브랜치를 분리해 개발한 후 최종적으로 메인 브랜치에 반영한다고 했을 때 기능 별로 독립적으로 개발이 가능하며 만약 브랜치 간 충돌이 발생한다면 최종 메인 브랜치에 반영하기 전에 충돌나는 부분만 수정해주면 된다.

브랜치 전략

앞서 브랜치를 왜 사용하는지 살펴봤다. 그럼 자연스럽게 떠오르는 것이 브랜치를 잘 사용하는 방법일 것이다. 오랜기간 브랜치를 사용하며 표준처럼 굳어진 브랜치 전략들이 여러개 있다. 사실 브랜치 전략에 대한 것은 이미 많은 글들이 있어 간단하게만 적어보려고 한다. 각 전략에 대해 자세한 내용이 궁금하다면 참고자료의 블로그 글을 참고하자.

Git Flow

Git Flow 전략

 

크게 Main brances와 Supporting brances로 구분된다. 다시 Main brances는 master, develop 브랜치로 구성되며 Supporting brances는 feature, hotfix, release 브랜치로 구성된다.

• master 브랜치는 실제 운영 중인 어플리케이션의 기반이 되는 브랜치이다.
• develop 브랜치는 기능개발 시 기준이 되는 브랜치이다.
• feature브랜치는 develop브랜치에서 분기해 독립적인 기능개발 시 사용하고 개발이 끝나면 develop 브랜치로 병합된다.
• hotfix브랜치는 버그가 났을 때 master브랜치에서 분기해 오류를 수정한 후 master, develop 브랜치로 병합된다.
• release 브랜치는 master브랜치에 병합되기 전에 최종적으로 자잘한 버그들을 고치는 등의 운영준비를 하는 브랜치이다. release 브랜치에서 master 브랜치로 합쳐지면서 버전에 대한 태그를 붙인다.

위 사진에서 알 수 있듯이 git flow는 master 브랜치에 병합되는 시점 별로 어플리케이션의 버전이 관리된다. 때문에 git flow 전략은 어플리케이션의 버전이 관리될 필요가 있는 라이브러리, 모바일 앱 등에서 주로 사용된다. 

Github Flow 전략

Github Flow 전략

 

git flow 전략은 어플리케이션 버전을 관리하기 용이하고 브랜치 별로 역할이 나뉘어져 있어 규모가 큰 조직에서 어플리케이션에 대한 체계적인 개발이 가능하다. 그런데 웹 서비스는 어떨까? 웹 서비스는 버전이 따로 필요하지 않다. 웹 서비스는 사용자의 환경 혹은 사용시점과 상관 없이 항상 하나의 버전만 제공한다. 또한 최근 개발 조직이 소규모로 구성되는 추세에서 브랜치 계층이 너무 많아지면 조직 규모에 비해 불필요한 과정들이 많아질 수 있다. 이런 git flow 전략의 문제를 극복하고자 github flow 전략이 나오게 됐다.

 

위 사진에서 알 수 있듯이 github flow 전략은 master 브랜치 하나를 두고 기능개발 혹은 버그 수정 등이 있을 때 master 브랜치에서 분기해 하나의 feature(topic) 브랜치를 만든다. feather 브랜치에서 작업이 끝나면 작업에 대한 검토(pull request)를 실시한 뒤 문제가 없으면 master 브랜치로 병합한다. git flow 전략에 비해 브랜치 계층이 매우 간단하고 master 브랜치에 병합되는 주기가 빠르다. 다만 github flow전략의 단점은 master 브랜치에 병합이 자주 일어 남에 따라 운영 중인 어플리케이션의 안정성이 떨어질 수 있다. 때문에 작업에 대한 검토과정이 철저하게 이루어져야 한다.

GitLab Flow

GitLab Flow 전략

 

GitLab Flow 전략은 Github Flow 전략의 단점을 보완하기 위해 나온 전략이다. Github Flow는 간단하다는 장점이 있지만 master 브랜치에 너무 과도한 책임이 부여되어 있다고도 할 수 있다. 이런 문제를 극복하기 위해 GitLab Flow에서는 어플리케이션의 운영에 대한 책임만 하는 production 브랜치를 구성한다. master 브랜치가 기준이 되고 feature 브랜치에서 기능개발을 한 후 master 브랜치에 병합하는 과정은 github flow하고 동일하나 master 브랜치가 어플리케이션 운영의 기준이 되지는 않는다. master 브랜치에서 추가적인 테스트나 보완을 완료하여 최대한 안정화를 거친 후 production 브랜치에 병합하여 최종 배포를 진행하게 된다. 만약 별도의 테스트 서버를 두어 실제 사용자가 이용하는 것처럼 테스트를 하고자한다면 pre-production 브랜치를 만들어 구성하기도 한다.

회사에서는...

글을 정리하면서 회사에서 관리하는 브랜치를 생각해보니 Git Flow와 GitLab Flow를 애매하게 섞어놓은 것 같다. main 브랜치가 운영 즉 production 역할, develop 브랜치가 개발 기준(master 브랜치 역할)과 pre-production(테스트서버 환경)을 하고 있다. 기능 개발 시  develop 브랜치를 기준으로 feature 브랜치를 만들고 있다. 아무래도 이전에 관리하던 브랜치들과 인원이 조정되며 현재 혼자 개발을 하면서 브랜치 전략에 대한 명확한 이해가 없이 개발을 진행해서 그런 것 같다. 현재 조직 규모나 환경 등을 생각했을 때 GitLab Flow 전략으로 정리하는게 필요할 것 같다.

프로젝트에서는...

프로젝트는 웹 기반이며 나 혼자 개발할 것이므로 Github Flow 전략을 채택하는게 좋아보인다. 즉 master 브랜치가 운영의 기준이고 기능 개발 시 feature 브랜치를 만들어 개발을 진행할 것이다. CI/CD 즉 지속적인 통합, 지속적인 배포가 이루어지는 기준 브랜치도 master 브랜치가 된다. 

 

참고자료

https://nvie.com/posts/a-successful-git-branching-model/

A successful Git branching model

https://hudi.blog/git-branch-strategy/

Git 브랜치 전략 (feat. Git Flow, Github Flow)

https://blog.hwahae.co.kr/all/tech/9507

Git 브랜치 전략 수립을 위한 전문가의 조언들 – 화해 블로그 | 기술 블로그