Gitflow, 협업기법 깃플로우 각 브랜치 역할 알아보기

 

 

Gitflow는 Git을 활용해서 협업을 할때 사용하는 하나의 협업기법으로, Vincent Driessen이라는 외국 분이 제안한 기법입니다. 

해당 기법은 우아한형제들 등 다양한 메이저 대기업, IT기업 에서도 각자 회사 입맛에 맞게 변형하여 사용하고 있을만큼, 알아두면 좋은 기본적인 개념이라고 생각합니다. 

하지만 gitflow 하고 처음 들으면 바로 이해하기는 쉽지 않다고 생각합니다.

저도 현업에서 실제 사용하지 전까지는 이게 뭔가 하고 어리둥절했던 기억이 있었습니다. 그래서 이부분에 대해서 상기할 겸 Git-Flow의 각 Brach 역할을 직접 정리해보고자 합니다~ 👨🏻‍💻

먼저 Vincent Driessen 님이 제안했던 Gitflow에 대한 그림을 보겠습니다. 

 

 

위의 Gitflow 설명 그림은 기본적인 Gitflow의 동작들을 한눈에 설명하고 있습니다. 

여기에서 각각의 브랜치에 대한 역할을 보겠습니다. 

■ master branch : master는 실제로 운영, 배포되어 사용자가 사용하게 될 코드가 있는 브랜치입니다. master 브랜치는 각 버전마다 태그를 갖고 있습니다. 가능하면 직접 건드리지 않으며, hotfixs / release 브랜치의 코드가 master 브랜치로 merge됩니다.
- master 브랜치가 바뀌는 경우는 일반적으로 아래와 같습니다.
  - 일반적인 버전 업데이트 : release 브랜치에서 충분한 QA(Quality Assuarance) 절차가 이루어졌다고 판단되면 해당 코드를 master로 merge하고 태깅 및 배포작업을 거칩니다.
  - master에서 급한 이슈가 발생했을때 : 운영중인 서비스앱이 긴급한 이슈가 발생할 수 있죠. 이럴때는 정형적인 절차를 거치면 매우 시간이 부족할 수 있겠습니다. 이때는 hotfix 브랜치를 통해서 긴급이슈를 수정하고 master로 다시 merge하는 방식으로 master가 바뀌기도 합니다. 이건 회사 사정에 따라 급하게 master 브랜치에서 수정작업을 할 수도 있겠지만, 가능하면 hotfix의 절차는 거치는게 안전할 것 같아요. master는 가능하면 건들지 않는것이 안전하겠죠?

■ develop branch : develop은 QA단계를 거치기 전에 배포를 위해 적용되어야할 개발이 이루어지는 브랜치입니다. 그렇다고 모든 개발자들이 develop브랜치에서 수정을 하는 것은 아니구요. 기능개발의 규모나, 성격에 따라서 develop으로부터 feature 브랜치를 분리해서 작업을 하게 됩니다.

 다음 QA를 앞두고 QA가 필요한 기능들은 feature브랜치에서 develop브랜치로 merge작업을 하고나서 QA단계를 가게 됩니다. QA단계에 가면 develop브랜치 코드에서 release브랜치가 분리되어서 release브랜치에서 QA단계가 진행이 됩니다. 

 

 

develop 브랜치는 배포를 앞둔 기능들의 집합체라고 할 수 있을 것 같아요. release 브랜치에 merge되기 전까지 배포전까지 구현해야할 기능들이 쌓이는 브랜치입니다.

■ feature branch : feature브랜치는 말 그대로 특정 기능을 개발하는 브랜치입니다. 보통 develop 브랜치에서 분리되고, 기능 개발이 완료되면 develop브랜치로 다시 merge됩니다. 하지만, 기능개발이 완료되었다고 무작정 develop브랜치로 merge되면 안됩니다. 왜냐하면 develop브랜치에서 추후 QA, 배포단계를 거치면서 release 브랜치가 나뉘는데 이때 아직 배포되면 안될 기능이 있을 수 있어요.

 이 경우에는 develop브랜치에 merge하지 않고, feature 브랜치에서 대기를 하는 겁니다. 꼭 필요한 기능한 develop으로 merge되고, 이후에 release 브랜치에서 QA를 작업합니다. (처음 보시는 분들을 위한 설명이니 계속 반복되는 내용을 설명하는 점 이해 부탁드립니다~ 😂)

 

 

 

다음 배포에 적용되어야 할 기능에 대해서만 develop 브랜치로 merge됩니다. 아직 배포하면 안되는 기능은 대기했다가 다음 배포때 develop 브랜치도 merge 됩니다!

 

 

■ release branch : release 브랜치는 배포를 앞둔 단계에서 QA를 진행하는 브랜치입니다. QA팀에서 현재까지 구현한 코드의 기능이 정상적인지를 테스트하고, 이슈가 발생했을때 PM, 개발 팀 등에 해당 상황을 보고합니다. 그렇게 탁구치듯이 핑퐁핑퐁이 이루어집니다.

 이과정에서 release 브랜치에서는 발견된 이슈들이 수정되겠죠? 이렇게 QA단계를 거치고, 배포시점이 되면 release 브랜치의 내용을 master, develop 브랜치 두곳으로 merge합니다. 

 

 

위의 사진을 보시면, release 브랜치가 merge될 때에는 master, develop 브랜치로 머지되는 것을 보실 수 있죠?

 

 

■ hotfixs branch : 핫픽스 브랜치는 긴급 수정 브랜치라고 보시면 됩니다. 앞서 말했듯이, master 브랜치 코드, 즉 이미 운영중인 서비스에서 긴급한 이슈가 발견되면 급하게 고치는 겁니다.

 급하게 hotfixs 브랜치로 이동해서 수정이 되면, develop, master 브랜치로 merge됩니다. 이 merge 방식은 release 브랜치와 유사하겠네요.

 

 

 

 

 

---

이렇게 지금까지 Git-flow의 기본적인 branch 별 역할, 시나리오를 돌아봤습니다. 깃플로우 협업방식에 대해, 각 branch의 역할에 대해서 어느정도 이해가 가셨나요?

이부분은 사실 이게 정답이다! 하는게 아닌, 기본적인 진행방식이라고 볼 수 있어요. 이러한 Git-flow의 방식에서 회사 사정 및 성격, 특색에 맞게 변형해서 사용하곤 합니다. 

깃플로우(Git-Flow)에 대해서 보셨는데요. 어떻게 생각하시나요? 좋은 협업기법이라고 생각이 드시나요? git-flow같은 협업기법의 활용을 통해 협업 간 개발자들간의 코드 충돌과 비효율적인 작업이 줄어들 수 있다고 생각하기때문제 중요한 부분이라고 생각합니다. 뿐만 아니라, master를 직접 수정하는 것이 아니기 때문에 실제 운영되는 서비스가 정상적으로 동작하기 위한 대처방식도 될 수 있을 거구요. 🤗

제가 적었던 GitFlow, 깃플로우 협업방식에 대한 의견이나 질문이 있으시면 언제든 환영합니다. 😆