Git Flow전략으로 브렌치 관리하기

지금까지 간단하게 Git과 GitHub를 사용하는 법을 알아봤다.
이제 이들을 이용해 협업할때 좋은 브렌칭 전략인 GitFlow를 알아보자

GitFlow가 뭔가요?

GitFlow는 git으로 프로젝트를 운용할때 브렌치를 파는 전략중 하나이다.
2010년 Vincent Driessen이 본인의 블로그 를
통해 제시한 브랜칭 전략이다. 최근들어 Github-flow, Gitlab-flow등 여러 브렌칭 전략도 나오고 있지만
개인적으로는 GitFlow가 제일 안정적인것 같다.

GitFlow 살펴보기

GitFlow의 원작자가 직접 사용한 그림이다.

메인 브렌치

• master
  구현을 완료했고, 충분히 테스트를 해 즉시 배포 가능한 상태인 브렌치다
• develop
  다음 배포 버전을 개발하는 브렌치이다.

보조 브랜치

• feature
  기능을 개발하는 브렌치이다.
  feature/기능명으로 브렌치 명을 사용해야한다.
  기능구현이 완료되면 develop로 머지되며, 브렌치는 제거된다.
• release
  develop 브랜치에서 다음 버전의 스펙이 맞춰졌다고 판단되었을 때 생성하는 브렌치이다.
  보통 기능테스트 등을 하며 버그를 발견하고 고치는데(QA라고 한다) 사용된다.
  위 과정이 완료되면 develop, master에 머지가 된다.
• hotfix
  master 브렌치에 있는(출시버전의)코드에서 발생한 버그를 수정하는 브랜치이다.
  hotfix/기능명으로 브랜치 명을 사용한다.

정리하기

Git의 브렌칭 전략인 GitFlow에 대해 알아보았다.
필자는 협업 프로젝트를 진행하면서 위 모델 + Merge할때마다 PR을 강제회 시키는 규칙을 애용하는 편이다.
우선 브렌치가 목적별로 나뉘면서 관리하기 편해진 점이 좋다.
거기에 브랜치를 판 후 PR을 올려 Merge하는 과정을 만들면서 자연스레
코드리뷰(GitHub의 PR을 사용하면 그 브렌치의 변경점이 한번에 보여 보기도 편하다)를 하게 되고,
팀원들의 코드 이해도도 높아져 회의와 코드 유지보수가 한결 쉬워졌다.