안녕하세요, 강남언니 서비스 백엔드를 담당하고 있는 제이슨입니다! 사용자가 불편함 없이 빠르고 안정적으로 더 좋은 의료 서비스를 이용할 수 있도록 하는 역할을 하고 있습니다.
이번 글에서는 아마 대부분 들어는 봤고 많은 분들이 실제로 쓰고도 있지만, 제대로 알아볼 시간은 없지 않았을까 싶은 GitFlow 에 대해 다뤄보려고 합니다.
GitFlow
아래의 글이 GitFlow 의 시작입니다.
https://nvie.com/posts/a-successful-git-branching-model/
당시에는 GitFlow 라는 이름도 없었네요 😁
저자는 1년 정도 이 방식을 도입하고 매우 성공적으로 작동해서 이 글을 올렸다고 합니다.
아래는 GitFlow 를 한눈에 볼 수 있는 이미지입니다.
복잡해 보이시나요? 😵 영어로 보면 더 복잡할까봐 한국어 번역을 해보았습니다.
아직 잘 이해 안되시더라도, 이 글을 한 번 쭉 보고 나시면 "아하! 별거 아니었네" 하실 수 있을 거에요.
GitFlow 의 구성
GitFlow 는 아래와 같은 branch 들로 구성되어 있습니다.
develop
master
feature
branchesrelease
brancheshotfix
branches
branch 를 merge 할 때는 항상 --no-ff
옵션을 붙여서 branch 에 대한 기록이 사라지는 것을 방지하는 것을 원칙으로 합니다.
branches
각 branch 들이 왜 만들어졌는지, 어떤 역할을 하는지 알아봅시다.
develop / master
GitFlow 는 develop
과 master
를 나누는 아이디어가 가장 핵심입니다. 따라서 다른 version 관리 방식과의 차별점이기도 합니다.
나머지 feature
, release
, hotfix
branches 는 develop
과 master
를 나눈 결정에 따라 자연스럽게 발생하게 됩니다.
master
는 현재 production 의 상태와 일치하는 branch 입니다.develop
은 현재 개발이 완료된 상태와 일치하는 branch 입니다.- 개발이 완료되었다는 것은 다음 릴리즈를 위해 언제든 배포될 수 있는 상태를 말합니다.
- 이 두 branch 는 (프로젝트가 존재하는한..) 영원히 존재합니다.
feature branches
- 문제 상황
develop
에서 새로운 feature 작업을 commit 했습니다.origin/develop
에 push 를 했습니다.- 앗, rejected! conflict 이 생겼어요 😓 누가 그 사이에 새로운 commit 를 올리셨네요.
- 목적
develop
을 현재 개발 완료 상태와 일치시키면서도 다른 동료와 conflict 가 생기지 않도록 작업하기 위해feature
branches 를 이용합니다. - 작업
develop
에서feature
branch 를 생성해서 새로운 작업을 시작합니다.- ex.
feature/ISSUE-101
- ex.
feature
branch 에서 작업이 끝나면feature
branch 를 최신develop
에 merge 합니다.- conflict 없이 깔끔하게 해결! (가끔 생길 때도 있지만요 🤫)
release branches
- 문제 상황
- 배포를 준비해볼까 합니다! 😁
develop
에서CHANGELOG.md
도 작성하고, version 명도 바꿔주고, ...- 이제
develop
을master
에 merge 하고 배포 하면 되겠지? - 앗! 문제가 발생했어요. 다음 release 의 feature 가 의도하지 않게 함께 배포 되어버렸네요 😓
- 목적
release 준비를 시작한 뒤에develop
에 merge 되는 다음 release feature 로부터 안전한 release 를 하기 위해release
branches 를 이용합니다. - 작업
develop
에서release
branch 를 생성해서 새로운 작업을 시작합니다.- ex.
release/1.1.0
- ex.
release
branch 에서 version bumping, minor bug fix 등의 작업이 끝나면release
branch 를 최신develop
과master
에 각각 merge 합니다.develop
:release
branch 에서의 bug fix 등 수정 사항들이 develop 에도 반영되어야 하기 때문에master
: 새 version 을 release 하기 위해
master
의 merge commit 에 version 을 tag 로 붙여줍니다.- ex.
1.1.0
- ex.
- 이렇게 하면
release
branch 를 생성한 후에develop
에 어떤 작업이 merge 되었어도 안전하게 배포 성공! 😁
hotfix branches
- 문제 상황
- production 에서 문제가 발견되었어요! 🔥
develop
에서 수정해서 올리려고 했는데... 이미 다음 release 의 feature 들이 commit 되어있어요.- 이럴 때는 어떻게 해야하죠? 😓
- 목적
develop
과 독립적으로 production 에서 발생한 문제를master
에서 처리하기 위해hotfix
branches 를 이용합니다. - 작업
master
에서hotfix
branch 를 생성해서 bug fix, version bumping 등의 작업을 진행합니다.- ex.
hotfix/1.1.1
- ex.
hotfix
branch 에서 작업이 끝나면hotfix
branch 를 최신develop
과master
에 각각 merge 합니다.develop
:hotfix
branch 에서의 bug fix 등 수정 사항들이 develop 에도 반영되어야 하기 때문에master
: 버그가 수정된 새 version 을 release 하기 위해
master
의 merge commit 에 version 을 tag 로 붙여줍니다.- ex.
1.1.1
- ex.
- 이렇게 하면
develope
의 작업과 상관없이master
에 bugfix 를 배포 성공! 😁
마치며
지금까지 GitFlow 에 대해서 알아보았습니다. 각 branch 이 왜 만들어졌는지 알고 나니 그동안 복잡하게 느껴졌던 GitFlow 가 좀 명확하게 느껴지시나요? 어떤 툴을 잘 알지 못하는 상태에서 사용한다면, 오히려 그 툴을 사용하는 것이 더 비효율을 만들어낼 수도 있습니다.
이 글에서는 GitFlow 에 대해서 얘기했지만, 그렇다고 GitFlow 가 절대 만능인 것도 베스트인 것도 아닙니다. GitFlow 가 풀고 싶은 문제는 versioning 을 기반으로 정기적으로 배포되는 시스템에서의 깔끔한 Git 관리 방법입니다.
하지만 CI/CD 를 지향하는 상황에서도 GitFlow 가 적합할까요? 그러면 매 release 마다 불필요한 작업이 너무 많이 필요할 것입니다.
그런 관점에서 GitFlow 를 신랄하게 까는 글 하나를 소개합니다.
Gitflow is a Poor Branching Model Hack
툴은 도구일 뿐, 그것에 종속이 되는 것이 아니라 목적에 따라 툴을 선택해야 한다는 것을 잊지 말아야 하겠습니다.