🤔 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을 사용한다면 필수로 알아두어야 하는 지식입니다. 리마인드 차 정리해보았는데 많은 분들께 도움이 되길 바랍니다.
혹시 글을 읽으면서 잘못된 내용이 있으면 댓글로 알려주시면 감사하겠습니다! 읽어주셔서 감사합니다! 😊
👏 참고
'Tools > Git&Github' 카테고리의 다른 글
Git rebase를 사용해서 커밋 정리하기 (0) | 2020.11.30 |
---|---|
Github & IntelliJ로 프로젝트 관리하기 (이슈 만들기, 브랜치 생성, PR날리기) (1) | 2019.09.02 |
깃허브 이슈 템플릿 만들기 (0) | 2019.05.20 |
깃(Git)에 대한 간단한 설명부터 레파지토리 생성 후 커밋, 푸쉬하기까지 (0) | 2019.01.21 |