쉽게 이해하는 Git Flow

🤔 Git Flow?

Git Flow 전략은 Git을 사용해서 개발 작업을 진행하는 프로세스입니다. 협업을 할 때 Git을 사용한다면 대부분 Git Flow 전략을 채택하기 때문에, 알아두는 것이 좋습니다.

단, Git Flow를 그대로 적용하기보다는 팀에 맞춰 변형해서 사용하는 것이 좋습니다.

---

🌳 Git Flow의 브랜치

Git Flow에서는 총 5개의 브랜치를 사용합니다. 각 브랜치에 대해 간단하게 알아보도록 하겠습니다.

• master
  • 실제 프로덕트로 배포하는 브랜치
  • master에 머지가 된다는 것은 프로덕트에 적용하는 것을 의미한다.
• develop
  • master에서 배포가 되었다면, 그다음 버전을 준비하는 브랜치이다.
• feature
  • 새 기능을 개발하는 브랜치
  • develop을 베이스 브랜치로 가지며, 완료되면 develop에 머지하고 릴리즈를 준비한다.
  • 보통 feature는 prefix로 두고, 뒤에 jira 티켓 번호를 붙이거나 기능명을 적는다.
    • feature/add-read-api-#133
    • feature-API-133
• release
  • 실제 프로덕트로 배포하기 전에, 최종 점검을 하기 위한 브랜치
  • develop에서 해당 브랜치를 생성하며, 버그가 있을 경우에는 release 브랜치에서 버그를 픽스한다.
  • 보통 release를 prefix로 두고, 뒤에 릴리즈 버전을 명시한다.
    • release/1.1.0
• hotfix
  • 프로덕트에서 예상하지 못했던 버그를 수정하기 위한 브랜치

---

🚀 Git Flow 시나리오

브랜치 설명만 봤을 때에는 감이 잘 안 올 수도 있습니다. 시나리오를 보며 차근차근 익혀보도록 하겠습니다. Git Flow에는 워낙 유명한 설명 사진이 존재하지만, 개인적으로 이해하기 쉽게 그림을 만들어보았습니다.

 

새 기능 추가

기존에 있는 레포지터리에 새 기능을 추가할 때 사용하는 Git Flow 시나리오입니다.

develop에서 feature 브랜치를 생성하고, 기능 개발이 끝나면 develop에 머지합니다. 그 이후에 develop을 베이스 브랜치로 release 브랜치를 생성하게 되는데요. 만약 QA 과정 중에 버그가 발생한다면 release 브랜치에서 fix한 후 커밋합니다. 그 이후 QA가 종료되면 release를 master, develop으로 각각 머지합니다. 그 이후에 master에서 버전을 태깅하고 배포합니다.

 

버그 수정

프로덕션에서 버그가 발생되어 버그를 수정하는 경우에는 hotfix라는 브랜치를 사용하게 됩니다.

master에서 hotfix 브랜치를 생성하고, 해당 브랜치에서 버그를 픽스한 후에 master, develop으로 각각 머지합니다. 그 이후에 master에서 버전을 태깅하고 배포합니다.

이 시나리오를 따라 직접 브랜치를 만들고, 머지하고, 태깅하는 작업을 해도 상관없지만 이 작업들을 편하게 하기 위해 git flow를 사용할 수 있습니다.

---

💪 Git Flow Tool

설치하기

해당 섹션은 macOS, Homebrew 기준으로 설명합니다. 만약 homebrew가 설치되어있지 않다면, homebrew를 먼저 설치해준 후에 진행해주세요!

$ brew install git-flow-avh

$ git flow version
# 버전이 나오면 정상적으로 설치 완료!

 

git flow는 git flow init 명령어를 통해 프로젝트마다 지정할 수 있습니다.

git flow init

# 모두 기본 값으로 git flow 세팅
git flow init -d

 

사용하기

Feature

# 1. feature/add-read-api 브랜치 생성 
# 2. feature/add-read-api로 checkout
$ git flow feature start add-read-api

# 1. develop으로 checkout
# 2. feature/add-read-api 브랜치를 develop에 머지
# 3. feature/add-read-api 브랜치 삭제
# -> 만약 PR 과정이 필요하면 이 명령어를 사용하지 말고 깃허브의 PR 기능을 사용하는게 좋다.
$ git flow feature finish add-read-api

# 원격 저장소에 feature/add-read-api 브랜치 push
$ git flow feature publish add-read-api

# 원격 저장소에서 feature/add-read-api 브랜치 pull
$ git flow feature pull origin add-read-api

 

Release

# 1. release/1.1 브랜치 생성
# 2. release/1.1로 checkout
$ git flow release start 1.1

# (*) PR을 통해 머지한 상태면 꼭 master에 checkout하고 master, develop pull 받은 후에 진행하기!
# 1. release/1.1을 master에 머지
# 2. release 버전(1.1)을 태그로 생성
# 3. release/1.1을 develop에 머지
# 4. release/1.1 브랜치 삭제
$ git flow release finish 1.1
$ git push --tags # 새로운 릴리즈가 포함된 master 브랜치를 태그와 push

# 원격 저장소에 release/1.1 브랜치 push
$ git flow release publish 1.1

# release/1.1 브랜치를 추적
$ git flow release track 1.1

 

Hotfix

# 1. hotfix/1.2 브랜치 생성
# 2. hotfix/1.2로 checkout
$ git flow hotfix start 1.2

# (*) PR을 통해 머지한 상태면 꼭 master에 checkout하고 master, develop pull 받은 후에 진행하기!
# 1. hotfix/1.2을 master에 머지
# 2. hotfix 버전(1.2)을 태그로 생성
# 3. hotfix/1.2을 develop에 머지
# 4. hotfix/1.2 브랜치 삭제
$ git flow hotfix finish 1.2

---

💛 맺으며

Git Flow 전략은 이미 많은 곳에서 사용하기 때문에 Git을 사용한다면 필수로 알아두어야 하는 지식입니다. 리마인드 차 정리해보았는데 많은 분들께 도움이 되길 바랍니다.

혹시 글을 읽으면서 잘못된 내용이 있으면 댓글로 알려주시면 감사하겠습니다! 읽어주셔서 감사합니다! 😊

---

👏 참고

• Command Line Arguments