💡 브랜치를 사용하는 이유
브랜치는 개발작업에서 중요한 역할을 한다. 우리는 왜 브랜치를 사용해야할까? 만약 브랜치를 사용하지 않는다고 생각해보자. 메인 브랜치에서 모든 작업이 이루어질탠데 하나의 기능을 위해 여러개의 커밋을 하다보면 메인 브랜치의 코드가 불완전한 상태로 존재하게 된다.
협업을 하게 된다면 더 큰 문제가 발생한다. 모든 개발자들이 메인 브랜치에서 작업하게 된다면, 각자의 코드를 다른 사람들이 건드릴 수 있게되며 큰 혼란이 생길것이다. 하지만 각각 브랜치를 파서 개발을하면 각자 독립적인 환경에서의 개발이 가능해진다.
💡 Git 브랜치 전략
그런데 이런 브랜치도 특정한 규칙없이 사용하다보면 혼란을 불러올 수 있다.
브랜치를 효과적으로 관리하는 사례인 Git Flow와 Github Flow에 대해서 알아보자.
Git Flow
Git Flow는 Vincent Driessen이 그의 블로그에 2010년에 올린 A successful Git branching model 이라는 글이 인기를 끌며 대중적으로 사용되게된 브랜치 전략이다.
Git Flow의 구성은 아래와 같다.
- Main 브랜치
- Develop 브랜치
- Supporting 브랜치
- Feature 브랜치
- Release 브랜치
- Hotfix 브랜치
Main 브랜치
출시 가능한 프로덕션 코드를 모아두는 브랜치이다. 배포된 각 버전을 Tag를 이용해 표시한다.
Develop 브랜치
다음 버전의 개발을 위한 코드를 모아둔다. 개발이 완료되면 Main 브랜치로 Merge한다.
Feature 브랜치
하나의 기능을 개발하기 위한 브랜치이다. Develop 브랜치에서 생성되며 완료 후에도 다시 Develop 브랜치에 Merge 된다.
Release 브랜치
소프트웨어 배포를 준비하기 위한 브랜치이다. Develop 브랜치에서 생성하며, 버전 이름 등 소소한 데이터를 수정하기위한 브랜치이다. 배포 준비가되면 Main과 Develop 브랜치 모두에게 Merge 한다.
Hotfix 브랜치
이미 배포된 버전에 문제가생기면 이용하는 브랜치이다. Main 브랜치에서 생성하며 문제가 해결되면 Main과 Develop 브랜치 모두에게 Merge 한다.
Git Flow의 한계: 웹 어플리케이션에는 적합하지 않다
Vincent Driessen은 A successful Git branching model을 작성하고 10년이 지난 2020년에 해당 포스팅 위에 반성의 글(Note of Reflection)을 적는다.
Git-Flow는 등장하고 10년 넘게 표준처럼 자리잡고, 더 나아가 마치 만병통치약처럼 사용되었다. 현재는 Git으로 관리되는 인기있는 유형의 소프트웨어가 웹 어플리케이션으로 이동하고 있다. 웹 어플리케이션은 일반적으로 롤백되지 않고, 지속적으로 제공(Continuous Delivery)되므로 여러 버전의 소프트웨어를 지원할 필요가 없다.
웹 어플리케이션은 내가(Vincent Driessen) 10년전 블로그 글을 쓸때에는 염두해둔 소프트웨어 유형이 아니다. 팀이 소프트웨어를 지속적으로 제공한다면, Git Flow 대신 Github Flow와 같은 더 단순한 워크플로우를 채택할 것을 제안한다.
그러나 명시적으로 버전을 관리해야하는 소프트웨어를 개발한다면, 여전히 Git Flow가 적합할 수 있다.
쉽게 설명하자면 스마트폰 어플리케이션, 오픈소스 라이브러리/프레임워크 같이 여러 버전을 사용자가 사용하고 따라서 병렬적으로 버전을 관리해야하는 프로젝트에는 Git Flow 전략이 적합하다.
하지만 웹 어플리케이션의 사용자는 항상 최신 단일 버전만을 사용한다. 여러 버전을 병렬적으로 지원할 필요가없기에 Git Flow 방식이 적합하지 않다.
그렇다면 웹 어플리케이션 같은 경우는 어떤 전략을 사용해야할까?
Git Flow보다 단순한 Github Flow 전략을 사용하는것이 좋다.
Github Flow
Github Flow는 이름 그래도 Github 환경에서 사용하기 적합한 브랜치 전략이다. 또한 자동화를 적극 활용한다.
Main 브랜치
Main 브랜치는 모든 커밋을 언제 배포하든 문제없어야하고, 언제든 브랜치를 새로 만들어도 문제가없는 상태여야한다. Main 브랜치의 모든 커밋은 빌드가 되고, 테스트를 통과해야한다.
Topic 브랜치
새로운 기능을 개발할때 사용하는 브랜치이다. Main 브랜치에서 생성하고, Git Flow 전략에 Feature 브랜치와 같은 역할이다. 또한 별도로 Hotfix 브랜치를 관리하지 않으며, 버그 수정도 Topic 브랜치에서 진행한다.
Github에서는 PR(Pull Request)라는 유용한 기능이 존재한다. 개발자는 기능을 개발하는 중 언제든 상관없이 PR을 개설할 수 있다. 개설된 PR에서 협업하는 사람들과 토론, 코드리뷰등을 할 수 있다.
토론과 리뷰가 끝났으면, 다른 사람들의 동의(Approve)를 얻고 Main 브랜치에 자신의 Topic 브랜치를 Merge한다. 단, 이때 Topic 브랜치는 자동화된 CI 빌드를 통과해야 Merge가 가능하다.
적합한 전략
만약 내가 개발하고있는 프로젝트가 웹 애플리케이션 처럼 단일 버전만의 관리가 이루어져도된다면 Github Flow 전략을 사용하는것이 바람직하다.
하루에 변경사항을 작은 단위로 신속하고 자주 병합/배포 할 수 있는 구조이며 자동화(CI/CD)를 실천하기 적합한 전략이다.
Reference
