[GIT] Git 브랜치 전략:Git flow, GitHub flow

Git 브랜치 전략은 다른말로는 브랜치 운영 방식이라 할 수 있습니다.

오늘은 브랜치 전략 중 유명한 Git flow와 GitHub flow를 알아보도록 하겠습니다.

Git Flow

Git flow 브랜치 전략에서 쓰이는 브랜치는 두가지 성격으로 나뉘게 됩니다.

Git Flow

항상 유지되는 메인 브랜치

1. master

    제품으로 출시될 수 있는 브랜치로

    가장 최신 버전은 언제나 실행 가능한 상태여야함

    (참고)

     master merge 후 master 브랜치에 태그를 추가해서 버전을 메모할 수 있습니다.

git tag 0.1

 

2. develop

    master가 언제나 실행 가능하도록 하는 과정을 develop에서 진행

    다음 출시 버전을 개발하는 브랜치

 

일정 기간동안만 유지되는 보조 브랜치 (머지 후 브랜치 삭제)

3. feature: 기능 개발하는 브랜치

   새로운 기능 추가 작업이 있는 경우  develop 브랜치에서 feature브랜치 생성

   언제나 develop 브랜치로부터 시작, develop 브랜치로 merge

   => 모든 기능이 merge 되었다면 브랜치를 지우고 release 브랜치에서 QA를 진행

 

4. release: 출시할 때 준비하는 브랜치

    새로운 기능 (feature 브랜치)의 QA에서 발견된 버그들은 모두 release 브랜치에서 수정

    QA가 무사히 완료됐다면, release 브랜치를 master과 develop 브랜치로 merge

    develop 브랜치로부터 시작, develop 브랜치로 merge

    계속 병합작업을 해줘서, 나중에  develop  브랜치와  충돌을 최소화함

 

5. hotfixes: 버그 픽스

    출시 버전에서 발생한 버그 픽스 긴급 반영

    출시를 앞두고 긴급 수정을 해야할 때 hotfixes 브랜치를 사용

 

Git Flow의 중요 정책

Git Flow에서의 중요 정책은 commit 로그를 남기는 것으로, 

출시를 할 때 master로의 머지는 commit 기록을 남겨야합니다.

때문에 아래와 같은 fast commit이 아닌

git merge release/0.2

아래와 같이 --no-ff (no fast forward)를 해줘서 commit 로그를 남겨줍니다.

no fast forward를 해준다는 것은 release와 병합하는 과정을 commit 로그에 남기는 것입니다.

git merge --no-ff realease/0.2

 

육안으로 보는 fast commit과 no fast forward의 차이

 

그렇다면 Git Flow는 어떨 때 쓰일까요?

버전 관리를 해야하는 소프트웨어 개발에 적합합니다.

예를 들면, 스마트폰 어플리케이션, 오픈소스 라이브러리/프레임워크 등의 프로젝트가 있겠죠?

때문에 대부분의 케이스에서 매우 복잡하지요.

 

조금 더 이해가 쉽게 예시를 들어보겠습니다.

배달의 민족 안드로이드 모바일 파트에서는 브랜치 전략으로 Git Flow를 사용하고있는데요.

해당 파트의 앱 개발 프로세스 `기획-디자인-개발-QA-출시`를  3주의 주기마다 진행하고, 

개발자 인원이 증원됨에 따라, 3주 이상의 작업기간을  필요한 기능들이 생기기 시작하며 Git Flow 브랜치 전략을 도입했다고 합니다.

 

반대로 Git Flow가 적합하지 않은 상황의 개발을 예로 들어보겠습니다.

Git Flow 관련 유명한 블로그를 작성했던 빈센트 Vincent Driessen 왈 

Git Flow는 웹 어플리케이션을 염두해두고 있지 않으며, 웹 어플리케이션 소프트웨어 개발의 경우 Git Flow보다는 GitHub Flow와 같은 더 단순한 워크플로우를 권한다고 했습니다.

 

이유로는,

웹어플리케이션은 특성상 항상 최신의 단일 버전만을 사용하고, 여러 버전을 병렬적으로 지원할 필요가 없기 때문입니다.

그리고 웹 어플리케이션은 하루에 몇번이고 릴리즈가 될 수 있기 때문이지요.

 

그저 규칙을 따른다면 문제가 없고 정말 좋은 브랜치 전략이겠으나, 복잡한 플로우때문에 사람들이 실수를 자주 범하는 Git Flow였는데요, 

깔끔한 history 정리를 목적으로 git flow의 rebase and merge전략이 존재하나. 여전히 GitHub Flow에 비하면 복잡합니다.

 

Rebase란? 

용어 그대로 베이스를 다시 설정하는 작업. 

Git rebase는 두 개의 공통 base를 가진 branch에서 한 branch의 base를 다른 branch의 최신 커밋으로 branch의 base를 옮기는 작업. 

git checkout feature/b
git rebase develop

 

rebase를 하지 않은 git graph

rebase를 한 git graph

 

 

그렇다면 이제 GitHub Flow에 대해서도 알아보겟습니다.

GitHub Flow란?

- 깃플로우와 다르게 굉장히 간단한 구조

- 말그대로 깃헙 환경에서 사용하기 적합한 브랜치 전략

- 자동화 적극 활용

 

1. main  브랜치

- 언제 배포해도 문제가 없어야하고, 언제든 브랜치를 새로 만들어도 문제가 없는 상태의 stable한 브랜치

- 모든 커밋은 빌드가 되고, 테스트를 통과해야함 (깃헙 플로우의 정책)

 

2. topic 브랜치

- 깃플로우의 피처 브랜치의 역할

- hotfix 브랜치를 관리하지 않으며 이를 topic 브랜치에서 진행

- main -> topic -> 기능명 으로 브랜치를 생성하되, 기능명은 명확한 이름으로 네이밍 (ex. user-content-cache-key)

- 기능이 완성되지 않았더라도 꾸준히 push (기능 -> topic)

  ㄴ 노트북 분실, 컴퓨터 고장, 등 사고로 인한 코드 유실 방지 목적

  ㄴ 꾸준한 push로 구성원 모두가 끊임없이 커뮤니케이션 가능

 

GitHub Flow의 중요 정책

GitHub Flow는 main 브랜치가 항상 빌드가 되어야하고, 테스트를 통과해야하는 것도 있지만,

개발 중 어느 순간이라도 개발자가 원하는 순간에 Pull request를 할 수 있는 정책이 있습니다.

 

스크린샷, 아이디어, 에셋 등 무엇이 됐든, 공유를 하고싶을 때도 PR이 개설되곤 합니다!

개발자들은 개설된 PR에서 토론을하고, 코드의 특정 라인을 선택해서 코멘트를 남기는 등 코드리뷰를 주고받는데요,

이때 토론과 리뷰가 끝났을 시, 다른 사람의 동의 approve를 받고 main 브랜치에 자신의 topic 브랜치를 머지합니다.

단 topic 브랜치는 자동회된 CI빌드를 통과해야 머지가 가능합니다.

 

그렇다면 GitHub Flow는 어떨 때 사용할까요?

=> 하루에 변경사항을 작은 단위로 신속하고 자주 병합/배포 할 수 있는 구조로, 진정한 자동화( CI/CD)를 실천하기 적합한 브랜치 전략

- 소규모 에자일일 경우

- 단일 릴리즈 버전밖에 존재하지 않을 시

 

여기까지 Git Flow와 GitHub Flow에 대해 정리를 해보았는데요, 

그 외에도 gitlab flow, trunk-based development와 같은 여러 브랜치 전략이 있다고 합니다.

 

GitLab Flow

 

Trunk-based Development

 

Reference

https://techblog.woowahan.com/2553/

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0

 

 

https://trunkbaseddevelopment.com/