Git 브랜치 전략

프로젝트를 진행하면서 급하게 수정 후 배포할 일이 발생했는데, 어떤 브랜치를 기준으로 수정해야될지 고민되는 상황이 있을 것이다. 또한 가장 최신 버전의 브랜치를 찾고 싶은데 찾기 힘든 경우도 있다. 이런 문제를 해결하기 위해 여러가지 브랜치 전략이 만들어졌다. 그 중 대표적인 Git Flow, Github Flow, Gitlab Flow를 정리해본다.

Git Flow

항상 유지되는 2개의 메인 브랜치(master, develop)와 역할을 완료하면 사라지는 3개의 보조 브랜치(feature, release, hotfix)로 구성되어 있다.

master: 제품으로 출시될 수 있는 브랜치.
develop: 다음 출시 버전을 개발하는 브랜치. 상시로 버그를 수정한 커밋들이 추가된다.
feature: 기능을 개발하는 브랜치. 항상 develop 브랜치에서부터 시작하게 된다. 기능 추가 작업이 완료되면 develop 브랜치로 merge 된다.
release: 이전 출시 버전을 준비하는 브랜치. develop 브랜치에 기능 추가가 완료가 되었다면 QA를 위해 develop 브랜치에서 만들어지는 브랜치다. QA를 진행하면서 발생하는 버그들은 여기서 수정된다.
hotfix: master에서 발생한 버그를 수정하는 브랜치.

Git%20%E1%84%87%E1%85%B3%E1%84%85%E1%85%A2%E1%86%AB%E1%84%8E%E1%85%B5%20%E1%84%8C%E1%85%A5%E1%86%AB%E1%84%85%E1%85%A3%E1%86%A8%204f5440fd92ad4bbda920b6ae96502fc9/Untitled.png

긴 호흡으로 개발하여 주기적으로 배포하고, QA, hot fix를 나누어 병렬적으로 수행할 수 있는 상황일 경우에 사용하면 좋은 모델이다. 하지만 너무 많은 브랜치로 인해 복잡하다는 단점이 있다.

GitHub Flow

GitHub의 pull request 기능을 이용한 전략이다. 배포할 수 있는 상태를 가진 master 브랜치를 둔다. 그리고 기능 개발, 버그 픽스 혹은 어떤 이유로든 master에서 브랜치를 만들어 개발한 후 merge한다.

Git%20%E1%84%87%E1%85%B3%E1%84%85%E1%85%A2%E1%86%AB%E1%84%8E%E1%85%B5%20%E1%84%8C%E1%85%A5%E1%86%AB%E1%84%85%E1%85%A3%E1%86%A8%204f5440fd92ad4bbda920b6ae96502fc9/Untitled%201.png

브랜치가 단순해서 이해하고 쉽고, 처음 Git에 접하는 사람에게 좋은 모델이다. 배포를 자동화 할 수 있다는 장점이 있다. 하지만 이는 배포, 환경, 릴리즈 등을 구분하지 않아 문제가 발생할 수 있다.

GitLab Flow

Github flow에서 모델이 너무 단순해져 발생하는 문제를 보완한 전략이다.

Git%20%E1%84%87%E1%85%B3%E1%84%85%E1%85%A2%E1%86%AB%E1%84%8E%E1%85%B5%20%E1%84%8C%E1%85%A5%E1%86%AB%E1%84%85%E1%85%A3%E1%86%A8%204f5440fd92ad4bbda920b6ae96502fc9/Untitled%202.png

마찬가지로 기능 추가, 버그 픽스 등을 master 브랜치에서 새로운 브랜치를 만들어 merge 시킨 후 릴리즈 또는 배포할 버전을 production 브랜치에 merge 시키는 방법이다. 앱스토어나 구글 플레이 같이 개발자의 의도대로 원하는 시기에 배포할 수 없는 환경에서 사용하면 좋다. 아래 사진과 같이 배포 전에 테스트를 해야된다면 pre-production 브랜치를 만들어 관리하는 방법으로도 만들 수 있다.

Git%20%E1%84%87%E1%85%B3%E1%84%85%E1%85%A2%E1%86%AB%E1%84%8E%E1%85%B5%20%E1%84%8C%E1%85%A5%E1%86%AB%E1%84%85%E1%85%A3%E1%86%A8%204f5440fd92ad4bbda920b6ae96502fc9/Untitled%203.png