Gitflow , Workflow 는 무엇일까?

JBoB·2023년 3월 7일
0

🐧Gitflow 란??

Gitflow 는 기능이 아니고 서로간의 약속인 방법론이다. Gitflow 는 feature 브랜치와 여러 브랜치를 사용하는 대안적인 Git 브랜치 모델이다.

git-flow는 Vincent Driessen의 branching model을 적용해 고수준으로 저장소를 관리할 수 있게 해주는 확장 기능이다. branching model은 feature - develop(dev) - release - hotfix - master 단계로 브랜치를 나눠 코드를 관리하는 전략이며 사용자가 쉽게 접근하고 사용할 수 있도록 확장 기능(명령어)을 제공하는 것이다. git-flow에는 5가지 브랜치가 있다. 항상 유지되는 주요 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있다

🐤Workflow

Workflow 는 “일이 흐른다”는 것을 의미한다. 큰 범위의 일을 수행하기 위해서는 그보다 작은 일들을 수행해야 하며 그 작은 일들은 상호 순서가 있어서 구 순서대로 일을 수행해야 한다는 큰 범위의 일을 수행할 수 있다는 것.

이런 개념들이 “일이 흐른다” Workflow 가 된다.

이러한 체계적인 일 단위, 순서, 연결 등에 대한 개념을 가지고 일의 흐름을 시나리오로 구성하고 이것을 시스템화해 구성한 것을 프로세스로 통칭한다.

🦊 Git Repository 구성

구성요소

  • Upstream Repository - 개발자들이 공유하는 저장소(최신 소스코드가 저장되어있는 원격 저장소)
  • Origin Repository - Upstream Repository를 Fork한 원격 저장소
  • Local Repository - 내 컴퓨터에 저장되어 있는 저장소

🦊 Flow Chart

  • Local Repository에서 작업을 완료한 한 후 작업 브랜치을 Origin Repository에 push
  • Github에서 Origin Repository에 push한 브랜치를 Upstream Repository로 merge하는 Pull Request를 생성하고 코드리뷰를 거친 후 merge

merge : “병합” 이라는 사전적 의미

  • 다시 새로운 작업을 할 때 Local Repository에서 Upstream Repository를 pull (최신 버전 다운로드)

🐤Gitflow Branch

🦊 Flow Chart

  • 처음에는 develop 브랜치와 master 브랜치가 존재. 하지만 develop 브랜치는 master에서 시작된 브랜치.

  • 새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성

    feature 브랜치는 언제나 develop 브랜치에서 시작!!!

  • 기능 추가 작업이 완료되면 feature 브랜치는 develop 로 merge!!

  • 배포에 충분한 feature 들이 확보되면 release 브랜치로 fork!!

  • 버그들을 수정하고 잘 통과되면 develop 브랜치와 master 브랜치로 merge

  • master 브랜치에서 버전 태그!!

🐶 Gitflow 시작하기

// 설치하기
$ brew install git-flow
// 실행하기
$ git flow init

🐶Develop 과 Master 브랜치

  • Master : 배포 가능한 브랜치
  • develop : 다음 버전 출시를 위해 개발한 브랜치

Master 브랜치는 공식 릴리즈의 History 를 저장하고 Develop 브랜치는 추가 기능들에 대한 통합 브랜치 역할을 한다. Main 브랜치의 모든 커밋에 대해 버전 번호를 적어두는 것이 좋다.

$ git branch develop
$ git push -u origin develop

master는 요약된 버전들을 포함하는 반면에 develop브랜치는 프로젝트의 모든 history를 포함

🐶 Feature 브랜치

feature브랜치는 부모 브랜치로 develop브랜치를 이용한다. feature 작업이 끝나면 develop
에 merge.

🚫 Feature들은 절대로 master 에 연결되면 안됩니다.

$ git checkout develop
$ git checkout -b feature_branch

git checkout -b feature/{기능 이름 또는 #이슈번호} develop

* branch off from develop : 분기 시작하는 브랜치는 devlelop을 사용합니다. 
* merge back into develop : 개발 완료 후 develop 브랜치로 병합합니다.

🐶 Release 브랜치

develop 브랜치가 배포에 충분한 feature들을 확보하게 되면 release 브랜치를 Fork 한다.

이 시점부터는 버그 픽스 , 문서 작업, 그 외 배포를 위한 필수 작업들을 제외하고 어떠한 새로운 feature 를 추가 할 수 없다. release 준비가 완료되면 master 브랜치와 develop 에 다시 한번 merge 한다.

* branch off from develop
 : 분기 시작하는 브랜치는 devlelop을 사용합니다. 
(develop 브랜치가 개발이 새 릴리즈 사항에 대해서 원하는 상태일 때)
* merge back into develop 또는 master
 : 개발 완료 후 develop/master 브랜치로 병합합니다.

// branch 이름 규칙을 갖는다.
git checkout -b realease/1.2

git checkout develop

// release 브랜치 종료하기
$ git checkout master
$ git merge release/0.1.0

🐶 Hotfix 브랜치

핫픽스 (hotfix) 브랜치는 production 배포들에 대해 빠르게 덧대기 위한 브랜치 입니다. release & feautre 브

랜치와 유사하지만 develop이 아닌 master 브랜치를 기반으로 한다는 점이 다릅니다.

유일하게 master에서 fork 할 수 있는 브랜치

이러한 작업은 팀이 다음 배포 사이클을 기다리거나 업무흐름에 대한 방해 없이 이슈를 관리할 수 있도록 한다.

// 브랜치 생성하기
$ git checkout master
$ git checkout -b hotfix_branch

// 브랜치 종료하기 
$ git checkout master
$ git merge hotfix_branch

$ git checkout develop
$ git merge hotfix_branch

$ git branch -D hotfix_branch
profile
간절하고 치열하게 살자

0개의 댓글