Git Flow vs Github Flow vs Git Lab Flow

Git Flow

기본 브런치는 5가지를 이야기한다. feature > develop > release > hotfix > master 브런치가 존재하며, 머지 순서는 앞에서 뒤로 진행된다. release 브런치와 hotfix 브런치의 경우, develop 브런치의 오른쪽에 존재하기에 모두 develop 브런치도 머지를 하도록 구성이 되어있다. Vincent Driessen은 관련하여 스크립트로 명령을 구성해놨으며, 그냥 설치를 하여 CLI에서 명령으로 작업을 하여도 되고, GUI 툴들에서 기본 내장 git-flow 명령이나 플러그인을 설치하여 작업을 진행할 수 있도록 보편화되어있는 브런칭 모델이다.

아래는 Git Flow 를 설명할 때 사용되는 대표적인 그림이다.

특징

• Matser Branch

가장 중심이 되는 브런치이며, 이 브런치는 현재 사용자들에게 서비스 되고 있는 시스템이라고 생각하면된다.

• Develop Branch

Master 브런치에서 나오며 개발중인 시스템이다. 현재 Master 브런치에서는 사용자들에게 직접적으로 사용하지만 Develop 브런치는 일반 사용자들이 접근할 수 없다.

• Release Branch

흔히 말해 테스트 서버라고 생각하면된다. 새로운 Production 릴리즈를 위한 브런치이다. Release 브런치에서 문제가 생기면 다시 Develop 브런치로가서 추가 개발을 하게된다. release 브런치에서는 버그 픽스에 대한 부분만 커밋하고, 릴리즈가 준비되었다고 생각하면 master로 merge를 진행한다.

• Feature Branch

Develop 브런치에서 나오며, 새로운 기능을 추가하는 브런치이다. 예를 들어 웹 사이트를 만들게 되면 login 기능, 메뉴 선택기능, 게시판 글쓰기 기능과 같이 모듈 단위로 추가가 된다.

• Hotfix Branch

Master 브런치에서 생긴 긴급한 오류를 해결할 때 Hotfix 브런치로 이동이 된다. 이미 유저들에게 서비스가 되고 있는데 발생한 오류라 최대한 빨리 해결할 때 브런치를 사용한다. 하지만, 큰 문제라 오랜 시간이 걸리는 경우 Develop 브런치로 합쳐 해결하게된다.

장점

• 명령어가 나와있다.
• 웬만한 에디터와 IDE에는 플러그인으로 존재한다.

단점

• 브런치가 많아 복잡하다.
• 안 쓰는 브런치가 있다. 그리고 몇몇 브런치는 애매한 포지션이다.

GitHub FLow

그림으로 먼저 보겠습니다.

Git 과 비교하면 상당히 단순하다. 흐름이 단순한 만큼 룰도 단순하다. master 브런치에 대한 role만 정확하다면 나머지 브런치들에는 관여를 하지 않는다. 그리고 pull request 기능을 사용하도록 권장을 한다.

사용 방법

• Master 브런치는 항상 최신 상태로 유지되어있고 서비스까지 진행이 되므로 엄격한 role(규칙)이 정해진다.
• git flow 와는 다르게 feature 브런치나 develop 브런치가 존재하지 않는다. 그렇기에 새로운 기능을 추가하거나 버그를 해결하기 위한 브런치의 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주어야 합니다. Github 페이지에서 보면 어떤 일들이 진행되고 있는지를 알아볼 수 있어야 하기 때문입니다.
• 피드백이나 도움이 필요할 때는 pull request를 이용합니다. pull request는 코드 리뷰를 도와주는 시스템이다. 그렇기에 이것을 이용하여 자신의 코드를 공유하고, 리뷰를 받을 수 있도록 한다. 물론 merge가 준비 완료되어 master 브런치로 반영을 요구하여도 된다.
• master로 merge가 일어나면 hubot을 이용하여 자동으로 배포가 되도록 설정해놓는다.

특징

• release 브런치가 명확하지 않은 시스템에서 사용에 맞게 되어있다.
• 여기에는 GitHub의 서비스 특성상. 릴리즈라는 개념이 없는 서비스를 진행하고 있어서 그런 것으로 보이며, 웹 서비스들이 릴리즈라는 개념이 없이지고 있으니 사용하기 편할 것으로 보인다. hotfix와 가장 작은 기능을 구분하지 않는다.
• 어차피 둘 다 개발자가 수정해야 되는 일중에 하나이다. 단지 우선순위가 어디가 높냐라는 단계이다.

장점

• 브런치 전략이 단순하다.
• 처음 git을 접하는 사람에게 정말 좋은 시스템이 된다.
• Github 사이트에서 제공하는 기능을 모두 사용하여 작업을 진행한다.
• 코드 리뷰를 자연스럽게 사용할 수 있다.
• CI가 필수적이며, 배포는 자동으로 진행할 수 있다.

단점

• CI와 배포 자동화가 되어있지 않은 시스템에서는 사람이 관련된 업무를 진행한다.
• 많은 pull request가 올라오기 시작하면 관리하기가 어려워진다.

GitLab Flow

Github에서 말하는 flow는 너무나도 간단하여 배포, 환경 구성, 릴리즈, 통합에 대한 이슈를 남겨둔 것이 많으며, Git과 Github의 중간단계(?)라고도 생각하시면 쉽습니다.

production 브런치가 존재하여 커밋한 내용들을 일방적으로 디플로이를 하는 형태. production 브런치가 실질적으로 서비스하는 브런치라고 생각하면된다.

Git Flow처럼 Release 브런치를 추가한 형태도 존재한다.

중간에 Pre-Prdocution 브런치를 추가시켜 개발한 내용을 바로 반영하지 않고 중간에 Staging 하는 공간을 만들었다.

Git Flow와 반대의 형태라고 생각하면 편하다.