Git 브랜치 전략 종류 (Git Flow, Github Flow, Gitlab Flow, Simple Branching Strategy) : Programming Story

1. Git 브랜치 전략의 의미와 필요성

깃(Git) 브랜치 전략은 협업하는 개발자들이 프로젝트를 효율적으로 관리하기 위한 전략이다. 만약 branch 관리에 명확한 기준이 없으면 이 브랜치는 어떤 목적으로 생성되었으며, 새로운 브랜치를 생성할 때 어떤 명명규칙으로 생성해야 되고, 프로젝트에서 브랜치들을 어떻게 관리해야 하는지 혼란이 올 수 있다.

따라서, Git 브랜치를 효과적으로 관리하기 위한 work flow가 필요하고 이를 위해 Git 브랜치 전략을 수립한다.

2. Git Branch 전략의 종류

다양한 브랜치 전략이 있지만, 그 중에서도 가장 널리 사용되는 것 중 몇 가지를 살펴보겠다.

1) 기본 브랜치 전략 (Simple Branching Strategy):
- 기본 브랜치 전략은 가장 기본이 되는 형태의 브랜치 전략으로, 주로 작은 규모의 프로젝트나 개발팀이 적은 경우에 사용된다.
- 보통 master 브랜치를 메인 브랜치로 사용하고, 각 개발자는 feature 브랜치를 생성하여 작업을 진행한다.
- 그리고 각 feature 브랜치에서 작업이 완료되면, 해당 기능이 master 브랜치에 통합된다 .
2) Git Flow:
- Git Flow는 Vincent Driessen이 2010년에 그의 블로그 "A successful Git branching model" 이라는 글을 통해 제안한 모델로, 크고 복잡한 프로젝트에서 많이 사용된다.
- - master branch
- - master 브랜치는 항상 배포 가능한 상태를 유지하며 master 브랜치에는 프로덕션 환경에서 실행 가능한 코드만 merge 된다.
  - 모든 기능이 개발 되고 QA(Quality Assurance)를 통과하고, 릴리스될 준비가 되면 develop 브랜치로부터 병합된다.
- - develop branch
  - develop 브랜치는 다음 릴리스를 위한 개발이 진행되는 branch라고 할 수 있다. 새로운 기능이나 개선 사항이 개발되는 주요 브랜치이며 통상적으로 팀의 모든 개발자들이 develop 브랜치를 기반으로 작업을 진행한다.
- -feature branch
  - feature 브랜치는 이름이 의미하는 바처럼 새로운 기능을 개발할 때 사용되는 브랜치이고 각 기능은 개별적인 feature 브랜치에서 개발된다. 흔히 우리가 feature/ ~ 이런 식으로 feature/기능이름으로 브랜치를 만들게 되는데, 해당 기능을 새로 개발할 때 feature branch도 생성한다. feature branch에서 개발이 완료되면 develop 브랜치로 병합된다.
  - release branch
- - release 브랜치는 다음 릴리스를 준비하는 동안에 사용되는 브랜치이다. 주로 develop 브랜치에서 분기되어, QA 테스트와 버그 수정이 함께 이루어진다.
  - 버전 번호를 업데이트하고, 릴리스 노트를 작성하며, 배포를 위한 최종적인 테스트를 진행하는 중요한 브랜치이다. 테스트와 버그 수정이 완료되면 master와 develop 브랜치로 merge 된다. master 브랜치에는 태그를 생성할 수 있는데 release 브랜치에서 master branch로 머지되면서 릴리스를 마킹한다.
- -hotfix branch
- - hotfix 브랜치는 배포된 소프트웨어에 긴급하게 버그 수정이 필요한 경우에 사용되는 브랜치이다. 배포된 소스에서 수정할 때 사용하기 때문에 master branch에서 분기된다.
  - 다른 브랜치와 동일하게 수정이 완료되면, master와 develop 브랜치로 merge 되고 master 브랜치에 태그를 생성하여 새로운 버전을 마킹한다.
3) GitHub Flow:
- 깃허브(GitHub)에서 제안된 간단한 협업 전략으로, 오직 master 브랜치만 사용한다. 빠른 릴리스와 지속적인 배포에 적합한 스타일이다.
- GitHub Flow에서는 주로 하나의 메인 브랜치인 master 브랜치만을 사용하기에 별도의 브랜치가 필요하지 않지만 각 기능 또는 수정사항의 경우 master 브랜치에서 분기된 개별 브랜치에서 개발되며 "feature" 또는 "bugfix"와 같은 이름으로 명명한다. - Master branch:
  1. - master 브랜치는 메인 브랜치로서 배포 가능한 상태를 유지해야 하며 리뷰 등을 통해 승인된 코드는 이 브랜치로 병합된다.
  2. - Feature branch (Bugfix branch):
    - 새로운 기능 또는 버그 수정을 위한 개별 브랜치를 생성한다.
    - 보통 feature/기능이름 또는 bugfix/bug번호 와같은 형식으로 브랜치가 생성되고 해당 기능이나 수정이 완료되면, 해당 브랜치가 master 브랜치로 Pull Request를 통해 merge 된다.
  팀이 소규모의 agile 팀이고 하나의 release 버전만을 관리한다면 github flow가 적합한 스타일이다. 하루에도 변경사항을 주기적으로 merge/ release 하기에 적합한 branch 전략이다.
4) GitLab Flow:

GitLab Flow는 GitLab의 기능인 CI/CD (Continuous Integration/Continuous Deployment)와 연계하여 사용된다는 것이 가장 큰 특징이다.

GitHub Flow에서새로운 변경 사항이 master 브랜치에 병합될 때마다 자동으로 배포되었다면 GitLab Flow에서는 릴리스 브랜치를 사용하여 배포를 준비하고, CI/CD pipeline을 통해 배포를 자동화한다는 것이 차이점이다. 특히 gitlab flow에서는 staging/ production 과 같은 환경을 나누어 테스트와 배포를 관리할 수 있다.

3. Git Branch 전략 종류 선택

각 종류별로 장, 단점이 모두 존재하기 때문에 조직, 프로젝트, 구성원 등에 따라서 가장 적합한 브랜치 전략을 수립하여 적용시키는 것이 중요하다.