Git 브랜치 전략 3가지

브랜치 전략이란?

브랜치 전략이란 여러 개발자가 1개의 저장소를 사용하는 환경에서 효과적으로 활용하기 위해 나온 개념입니다.

브랜치 전략은 Git flow, GitLab flow, Github flow 3가지가 대중적으로 알려져 있습니다.

 

목차

 

 

1. Git Flow

3 가지의 브랜치 전략 중 가장 먼저 나온 모델이다.

Git Flow

• feature > develop > release > hotfix > master 브랜치가 있다.
  • 머지 순서는 앞에서 뒤로 진행된다.

1.1. 브랜치 구성

브랜치명	구분	설명	비고
feature	보조 브랜치	기능 단위 개발 브랜치 feature에서 개발 완료 후 release로 merge Issue List로 브랜치 생성 및 관리	브런치 나오는 곳 : develop 브런치가 들어가는 곳 : develop
develop	유지 브랜치	하나의 기능인 feature가 모이는 개발 브랜치
release	보조 브랜치	개발된 내용을 배포하기 위해 준비하는 브랜치 (통합 테스트 브랜치) 테스트 완료 후 master로 merge 소스 프리징을 해결하기 위한 브랜치	다중 구성 가능 하위 브랜치 금지
hotfix	보조 브랜치	운영 중 긴급한 오류를 해결하기 위한 브랜치
master	유지 브랜치	기본 브랜치 언제든지 배포 가능한 형태를 유지	protected branch Maintainer 이상 관리

• 참고 : http://blog.hwahae.co.kr/all/tech/tech-tech/9507/

• 위 브랜치 전략 전제 요건
  • 정기 배포
  • 버저닝이 필요한 애플리케이션

---

2. GitHub Flow

GitHub Flow는 Git Flow가 Github에서는 사용하기가 복잡하다고 하여 나온 전략으로 위 3개의 전략 중 가장 간단한 전략입니다.

2.1. 특징

• 현재 GitHub 에서 실제로 사용하고 있는 브랜치 전략
• GitHub flow는 main 브랜치 하나만을 가지고 진행하는 방식이다.
• release 브랜치가 명확하지 않은 시스템에서 사용에 맞게 되어있다.
  • 릴리즈 없이 하루에 수십번 배포하는 시스템
  • 웹 서비스들이 릴리즈라는 개념이 없이지고 있으니 사용하기 편할 것으로 보인다.

2.2. 사용방법

1. main 브런치는 어떤 때든 배포가 가능하다.

• merge 후 main 으로 push 되면 즉시 배포한다.

2. 새로운 일을 시작하기 위해 브런치를 main에서 딴다면 이름은 어떤 일을 하는지 명확하게 작성한다.

• github flow 에서는 feature 브랜치나 , develop 브랜치가 존재하지않음
• 브랜치명은 user-content-cache-key , submodules-init-task 같이 명명하여, 브랜치가 어떤 코드 작업을 하는지 파악할수 있도록 한다.

3. 원격지 브런치로 수시로 push를 한다.

• 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다.

4. 피드백이나 도움이 필요할 때, 그리고 머징 준비가 완료되었을 때는 pull request를 생성한다.

• release 브랜치가 없으므로 이 과정이 탄탄하게 진행되어야 한다.
• 기능에 대한 모든 리뷰, 승인이 끝나면 main 브랜치로 머지한다.

5. main로 머지되고 푸시되었을 때는 즉시 배포되어야 한다.

• git hub flow 의 핵심, main 으로 머지가 되면 hubot 을 이용하여 자동으로 배포되도록 설정

 

---

3. GitLab Flow

GitHub flow 가 배포, 릴리즈에서 문제점을 갖고있다고 지적하며 나온 브랜치 전략이다.

브랜치는 feature , master (main) , production 가 있다.

• feature 는 기능을 개발하는 브랜치
• master (main) 는 git flow 개념에선 devleop 브랜치와 같다.
• production 는 실제 배포하는 브랜치이다.

3.1. Production branch with GitLab flow

3.2.Environment branches with GitLab flow

• master와 production 사이에 pre-production을 두어 개발한 내용을 곧장 반영하지 않고 시간을 두고 반영을 하는 것을 말한다.
• Pre-Production 은 스테이징 (Staging) 브랜치 정도로 생각하면된다.
• Test / Staging / Production

3.3.Release branches with GitLab flow

• release 한 브랜치를 두고서 보안상 문제가 발생한 것이나 백 포트를 위해서 작업을 할 경우, cherry-pick을 이용해서 작업을 진행할 수 도 있다.
• 해당 릴리즈에서 발생하는 버그들을 묶어서 수정하는 방식으로 작업한다. (upstream first 정책)

3.4. 개발 순서

• Clone
  • Master > Feature
• Merge
  • Feature > Master > Production

Master 브랜치가 배포 대상이 아닌 유일한 브랜치이다. 배포는 Production 브랜치에서 배포하며, Master 브랜치에 최종 머지되더라도 자동으로 CI/CD 파이프라인을 태우지 않는다.

---

4. 요약

복잡도

• GitHub Flow < GitLab Flow < Git Flow

배포 민첩성 / 배포 빈도

• GitHub Flow > GitLab Flow > Git Flow

위 브랜치 전략 중 정답은 없다.

각 팀의 상황과 문화에 따라서 적합한 브랜치 전략이 있기에, 충분한 논의를 통한 브랜치 전략 생성이 필요하다.

---

참고

• Git Flow https://nvie.com/posts/a-successful-git-branching-model/
• Git Lab Flow https://docs.gitlab.com/ee/topics/gitlab_flow.html
  • GitLabFlow https://postd.cc/gitlab-flow/
• Git Hub Flow https://docs.github.com/en/get-started/quickstart/github-flow
  • https://scottchacon.com/2011/08/31/github-flow.html
• https://blog.banksalad.com/tech/become-an-organization-that-deploys-1000-times-a-day/