[Git/Github] Git-Flow 개념 이해

qufdl·2023년 3월 9일
0

Git/Github

목록 보기
1/2

Git Branch 전략


우리는 기능을 하나씩 개발할 때, 혹은 협업을 할 때 깃의 브랜치를 활용한다. 브랜치를 활용하면 다른 브랜치에 영향을 받지 않고 여러 기능을 여러 사람들이 병렬적으로 개발할 수 있다.

하지만 협업을 할 때 특정한 규칙을 정해놓지 않으면 다음과 같은 의문점이 생길 수 있고, 이는 프로젝트 진행에 문제가 될 수 있다.

  • 누가 어떤 목적으로 생성한 브랜치인가?
  • 어떤 커밋에서 분기된 브랜치인가?
  • 내 커밋은 어디에 병합해야 하는가?

→ 이러한 문제점을 해결할 수 있는 것이 Git Branch 전략이다.

Branch 전략이란?

Branch 전략은 Git 브랜치를 효과적으로 관리하기 위한 워크플로어다. 거의 모든 기업들은 자신들의 상황에 맞는 Branch 전략을 사용하고 있다. 대표적인 Branch 전략에는 GitHub Flow, Git Flow, GitLab Flow 등이 있다. 이번 시간에는 그 중 Git Flow 전략에 대해 살펴볼 것이다.

Git-Flow


깃플로우git-flow 전략은 소스코드를 관리하고 출시하기 위한 Git Branch 전략 중 하나다. Git flow는 2010년에 Vincent Driessen가 블로그에서 제안한 모델을 기반으로 만들어졌으며, 현재는 많은 기업에서 표준으로 사용하는 브랜치 전략이다.

Git Flow는 크게 Main 브랜치, Supporting 브랜치로 구분하여 브랜치를 관리한다.

메인 브랜치 Main Branches

  • Master 브랜치 : 제품으로 배포할 수 있는 브랜치
  • Develop 브랜치 : 개발자들이 다음 버전 개발을 하는 브랜치
  • 두 브랜치는 프로젝트 시작 시 생성되며, 개발 프로세스 전반에 걸쳐 항상 유지된다.

보조 브랜치 Supporting Branches

  • Feature, Release, Hostfix 브랜치가 있다.
  • 보조 브랜치는 메인 브랜치와 다르게 필요에 따라 생성되며, 역할을 모두 수행한 경우 삭제된다.

Feature 브랜치

  • 하나의 새로 기능을 개발하기 위한 브랜치

  • 브랜치가 분기되는 곳 : develop

  • 브랜치가 머지 되는 곳 : develop

  • Develop에 merge 후 삭제한다.

  • 네이밍 ex) feature/branch-name

Release 브랜치

  • 다음 버전 출시를 위해 준비하는 브랜치

  • 브랜치가 분기되는 곳 : develop

  • 브랜치가 머지 되는 곳 : develop, master

  • 버전 정보, 버그 수정 등의 QA(품질보증)을 진행한다.

  • Main 브랜치에는 tag를 이용해 버전을 표시한다.

  • 기능 개발은 금지된다

  • 네이밍 ex) release-*

Hostfix 브랜치

  • 이미 출시된 버전에서 버그가 발생하면 빠르게 수정하기 위해 생성하는 브랜치

  • 브랜치가 분기되는 곳 : master

  • 브랜치가 머지 되는 곳 : develop, master

  • 코드를 수정하는 중에도 develop에서는 개발을 지속할 수 있다는 장점이 있다.

  • master브랜치에서 분기되며, 문제 해결이 완료되면 develop & master 브랜치로 merge한다.

  • master로 merge 후에는 tag를 통해 이전 버전보다 높은 버전을 명시한다.

  • 네이밍 ex) hotfix-*

Git Flow 흐름


Git Flow 전략은 다음과 같이 소스 코드를 관리한다.

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

  1. master 브랜에는 정식 배포되어 사용 중인 v1.1버전이 올라와 있다.
  2. develop 브랜치에서는 다음 버전인 v1.2 개발중이다.
  3. v1.2 버전에는 기능1과 기능2를 추가하고자 한다. feature/기능1, feature/기능2 브랜치를 생성해서 각 기능별로 개발을 진행한다.
  4. feature 브랜치의 개발이 완료되면 develop 브랜치로 머지 한 후, feature 브랜치는 삭제한다.
  5. develop 브랜치에서 개발이 완료되었다고 판단되면 release 브랜치를 생성하여 QA를 진행한다. release 브랜치에서 버그를 발견하면 release 브랜치에서 버그 수정을 한다.
  6. 정식 배포 준비가 완료되었다고 판단하면 master와 develop 브랜치로 merge한다.
  7. master 브랜치에 v1.2버전 태그를 추가한다.

💡만약 이미 출시되어 있는 master 버전에서 버그가 발생하여 빠르게 수정해야 하는 경우 master 브랜치에서 hostfix 브랜치를 생성하여 오류를 수정한다. 오류 수정 후 master와 현재 개발 중인 develop 브랜치에 머지 한다.

Reference

profile
백엔드 개발자를 희망하는 학생입니다

0개의 댓글