이번 글에서는 아마 대부분 들어는 봤고 많은 분들이 실제로 쓰고도 있지만, 제대로 알아볼 시간은 없지 않았을까 싶은 GitFlow 에 대해 다뤄보려고 합니다.
GitFlow
아래의 글이 GitFlow 의 시작입니다.
https://nvie.com/posts/a-successful-git-branching-model/
당시에는 GitFlow 라는 이름도 없었네요 😁
저자는 1년 정도 이 방식을 도입하고 매우 성공적으로 작동해서 이 글을 올렸다고 합니다.
아래는 GitFlow 를 한눈에 볼 수 있는 이미지입니다.
복잡해 보이시나요? 😵 영어로 보면 더 복잡할까봐 한국어 번역을 해보았습니다.
아직 잘 이해 안되시더라도, 이 글을 한 번 쭉 보고 나시면 "아하! 별거 아니었네" 하실 수 있을 거에요.
GitFlow 의 구성
GitFlow 는 아래와 같은 branch 들로 구성되어 있습니다.
develop
master
feature branches
release branches
hotfix 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
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
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
이렇게 하면 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
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
이렇게 하면 develope 의 작업과 상관없이 master 에 bugfix 를 배포 성공! 😁
마치며
지금까지 GitFlow 에 대해서 알아보았습니다. 각 branch 이 왜 만들어졌는지 알고 나니 그동안 복잡하게 느껴졌던 GitFlow 가 좀 명확하게 느껴지시나요? 어떤 툴을 잘 알지 못하는 상태에서 사용한다면, 오히려 그 툴을 사용하는 것이 더 비효율을 만들어낼 수도 있습니다.
이 글에서는 GitFlow 에 대해서 얘기했지만, 그렇다고 GitFlow 가 절대 만능인 것도 베스트인 것도 아닙니다. GitFlow 가 풀고 싶은 문제는 versioning 을 기반으로 정기적으로 배포되는 시스템에서의 깔끔한 Git 관리 방법입니다.
하지만 CI/CD 를 지향하는 상황에서도 GitFlow 가 적합할까요? 그러면 매 release 마다 불필요한 작업이 너무 많이 필요할 것입니다.
그런 관점에서 GitFlow 를 신랄하게 까는 글 하나를 소개합니다.
Gitflow is a Poor Branching Model Hack
툴은 도구일 뿐, 그것에 종속이 되는 것이 아니라 목적에 따라 툴을 선택해야 한다는 것을 잊지 말아야 하겠습니다.
