깃 브랜치 전략 (Git Branch Strategy)

Git 에서는 동시에 여러 작업을 하거나 버전관리를 하기 위해 Branch를 사용합니다. 작업 영역을 분리하여 수정하고 관리하여 원래 버전과 합칠 수도 있습니다.

이러한 Git의 Branch를 관리하는 전략들을 깃 브랜치 전략이라고 합니다.

어떤 브랜치 전략을 사용할까?

0. 브랜치 전략의 종류

브랜치 전략의 경우 크게 2가지가 존재했었습니다. 첫번째는 Git Flow, 두번째는 Github Flow 입니다. 최근에는 Gitlab Flow 까지 등장하면서 크게 3종류의 브랜치전략이 존재한다고 생각하면 될 것 같습니다.

1. Git Flow

많은 회사와 팀에서 사용하고 있는 전략입니다.

특징

1. 용도에 맞게 브랜치를 분리해서 사용한다.

   (feature → develop → release → hotfix → master)

   • 병합순서는 앞에서부터 뒤로 병합
   • develop 과 master 브랜치는 중심이 되는 브랜치라서 무조건 있어야 함

2. 명확한 릴리즈(release) 버전 관리를 위한 브랜치를 따로 관리하기 때문에 한 버전에 대한 유지보수가 용의함

3. 기능 개발 단위 사이사이의 충돌 (conflict)을 최소화할 수 있음

4. 명확한 배포 기간과 주기적인 버전이 정해진 프로젝트에 적합

간단한 브랜치 설명

크게 5종류의 브랜치가 존재합니다.

master

• 제품으로 출시될 수 있는 브랜치

develop

• 다음 출시 버전을 개발하는 브랜치

feature

• 단위 기능을 개발하는 브랜치

release

• 이번 출시 버전을 준비하는 브랜치

hotfix

• 출시 버전에서 발생한 크리티컬한 버그를 긴급 수정하는 브랜치

2. Github Flow

Git Flow가 Github에서 사용하기에 너무 복잡하고, 절차가 많으며 빠르게 진행해야 하는 프로젝트에서 비효율적이기 때문에 최소한의 브랜치만 운영하는 브랜치 전략입니다.

특징

1. Git Flow에 비해 굉장히 간단한 구조
2. master 브랜치와 pull request 방식을 활용한 단순한 형태를 가짐
3. Git Flow와는 다르게 hotfix 브랜치나 feature, release 브랜치를 구분하지 않음 (우선순위는 존재)
4. 수시로 배포가 일어나고, CI / CD 파이프라인이 구성되어 있는 프로젝트에 유용함

간단한 브랜치 설명

master

• 프로젝트의 기둥점
• 프로젝트를 product에 배포할 떄 사용되는 브랜치

feature branch

• 새로운 일을 시작하기 위해 만드는 브랜치
• 항상 master에서 분기
• Git flow와는 다르게 feature, release, develop 등을 나누지 않음
• 자세하게 어떤 일을 하고 있는지에 대해 알 수 있도록, 이름을 명확히 작성해야함
• 커밋 메시지를 명확하게 작성해야 함
• merge 준비가 완료되면 Pull Request를 생성하여 코드를 공유하고 리뷰함
• Pull Request 에서 리뷰가 완료되었다면 master 브랜치로 반영을 요구함

3. Gitlab Flow

복잡한 Git Flow와 너무 간단한 Github Flow의 절충안

특징

1. Production 브랜치가 존재 (GIt Flow의 master 브랜치의 역할과 같음)
2. Gitlab Flow의 master 브랜치는 production 브랜치로 병합됨
3. pre-production 브랜치는 production 브랜치로 넘어가기 전에 테스트를 진행하는 브랜치

간단한 브랜치 설명

master

pre-production

• production 으로 넘어가지 전의 브랜치
• 테스트 등을 담당하는 브랜치

production

• 배포만들 담당하는 브랜치

feature branch

• Github Flow의 새로운 브랜치 처럼 사용

4. 직접 만들어서 사용중인 브랜치 전략

위 3가지의 브랜치 전략을 혼합해서 브랜치 전략을 만들어 사용하고 있습니다.

특징

1. main 브랜치, develop 브랜치, feature 브랜치로 크게 3가지의 브랜치 전략을 사용하고 있습니다.
2. feature 브랜치의 경우 Github에 작성한 이슈의 번호로 브랜치 이름을 작성합니다.
3. main 브랜치와 develop 브랜치는 계속 유지하고, feature 브랜치는 사용후 바로 삭제합니다.

간단한 브랜치 설명

main

• 초기 폴더 구조와 최악의 경우를 대비한 백업용 브랜치
• project 출시 전 develop 브랜치와 merge를 진행하며 main 브랜치를 기준으로 CI / CD를 구현하여 배포를 진행합니다.
• 배포를 담당하게 되는 브랜치이기 때문에 오류가 존재하면 안됩니다.

develop

• main 브랜치를 분기로 구현한 기능들을 모두 담고있는 브랜치
• main 브랜치와 merge를 할 경우 모든 오류 및 버그를 수정하여 merge를 진행해야 합니다.
• develop 브랜치에서 직접적인 commit은 허용하지 않습니다. 하지만 급한 error fix 작업을 진행하게 될 경우 hotfix! 로 commit을 진행해야 합니다.
  • 작성 예) hotfix!: 로그인 관련 오류 수정

feature

• 기능 구현을 진행하는 브랜치
• develop 브랜치를 분기로 생성하며 브랜치의 이름은 Github에 작성한 이슈의 번호로 작성합니다.
  • 작성 예) Feat/issue-#12
• 기능 구현을 완료했다면 develop 브랜치로 pull requests를 날려 이상이 없는지 확인합니다.
• conflict이 발생했을 경우 develop 브랜치와 현재 브랜치의 내용을 확인하여 최신 코드 내용으로 해결합니다.
• develop 브랜치로 merge를 진행했을 경우 remote와 local에서 해당 브랜치를 삭제합니다.
• merge 이후 추가적인 작업이 필요할경우 다시 Issue 작성을 하여 새로운 브랜치를 생성하여 작업합니다.
  • 절대 merge한 브랜치를 되살려서 사용하지 않습니다.