Git Flow, 그리고 Github Flow

가끔씩 이게 뭔가~하고 검색해봤던 git flow를 정리해보려고 한다.

적어도 내가 검색한 git flow에 대해 설명한 블로그글, 아티클들은 대부분 Vincent Driessen의 “A successful Git branching model”이라는 글(https://nvie.com/posts/a-successful-git-branching-model/)을 모태로 작성되었다는 것을 알게 되었다.

이 글을 훌어보다가 git flow의 핵심이라고 생각된 부분이 있었는데 바로 “Decentralized but centralized”라는 단락이었다. 간단히 정리하면 :

“(프로젝트에 참여한) 각각의 개발자는 origin을 pull & push한다. 그런데 섣불리 어떤 문제가 있는지 모르는 상태에서 섣불리 origin에 작업을 push하기 전에 동료 간의 pull & push을 주고 받는 것이 유용할 수 있다.”

그림을 보니까 어떤 의도인지 이해가 되었다. 다음과 같은 흐름으로 최대 5개(master, develop, release, feature, hotfixes)의 브랜치를 생성한다 :

1. master 를 만든다
2. master에서 분기한 develop 생성
3. 각 개발자들 develop에서 분기한 feature 를 각각 생성하여 개발 진행
4. 개발완료된 feature 브랜치는 develop으로 merge
5. develop에서 분기하여 release 생성
6. release는 말 그대로 배포될 것이기에 QA 진행 → QA 통과하면 배포 준비가 완료됨
7. 배포해야 하니까 release 를 develop, master로 merge
8. 이 때 main 각 코드 버전을 기록한 태그 생성 → 이후 진짜 배포
9. 그런데 배포에 버그가 생겨 빠르게 고쳐야 하면 → master 기반으로 hotfixes 생성
10. 버그를 잡아낸 후 hotfixes 를 develop, master에 merge

5개의 브랜치의 역할은 다음과 같다.

• master ; 배포용 브랜치
• develop ; 사실상 가장 중요한 브랜치 - 각 개발자들의 코드를 여기에 모은다
• feature ; 보통 각각의 개발자들의 작업 단위 (작을수록 좋다)
• release ; (이름과는 달리) 배포 전 QA받는 용도
• hotfix(es) ; 배포 후 버그를 수정하기 위한 임시 브랜치

◼︎ 계속 유지해야 하는 브랜치는 main, develop이다.
◼︎ feature, release, hotfix는 자기 역할을 다한 후 master, develop에 merge되어야 하며 merge이후에는 즉시 삭제해야 한다.

아니 그런데, Vincent는 10년 뒤인 2020년에 git flow에 대해 반성을 시전했다. 그것도 자신이 쓴 글의 윗 부분에 추가 코멘트로!

한 마디로 정리하면
“웹애플리케이션을 제공한다면 git flow보다 github flow가 더 낫다”
는 것! 일반적으로 roll back되지 않고 지속적으로 제공되는 웹앱은 여러 버전의 소프트웨어를 지원할 필요가 없기 때문이라고 한다. 그래서 지속적 배포되는 소프트웨어는 간단한 github flow를, 버전이 명시적으로 나뉘는 소프트웨어는 git flow를 쓰라는 것이다.

(이 부분에 대해서 멘토님께 “제공하는 서비스가 웹앱이라면 git flow의 5개 브랜치 중 hotfix가 불필요한 것?”이라는 문의를 드렸는데 -
전략은 회사마다 다르다 / 일반적으로 롤백하지 않는건 모든 프로덕트에 해당한다…라는 답을 주셨다.)

사례를 굳이 찾아보지 않더라도 2~3명 정도가 진행하는 소규모 프로젝트에 git flow로 브랜치를 여러 개 가져간다는 것은 생각만 해도 버거운 일일 수 있다. 그럴 때 github flow로 좀 쉽게 가자는 것이라 이해했다.

그러면 github flow가 무엇인지 알아보자.

그림을 보면 git flow보다 훨씬 단순해 보인다. github flow가 git flow와의 가장 크게 다른점은 master 브랜치가 언제든 배포 가능한 상태면 된다는 것. 더 정학하게는 master가 항상 최신, 버그나 문제 없이 안정한 상태로 배포가 가능한 상태라는 것이다.

새로운 작업을 추가하기 위해서 master에서 별도의 브랜치를 분기하며, 이 땐 브랜치는 이름은 추가되는 기능을 명확하게 드러내는 것이 좋다. 기능을 추가하면 pull request를 통해 코드 리뷰를 받은 후, 통과되면 master로 merge한다. master는 언제든 최신 상태이므로 즉시 배포하면 된다.

프로젝트의 상황에 맞게 git flow 또는 github flow를 잘 선택해서 사용하면 되겠다.

▶︎ 포스팅 작성을 위해 참고한 정보는 다음과 같습니다 ~ :

https://nvie.com/posts/a-successful-git-branching-model/

https://scottchacon.com/2011/08/31/github-flow.html

https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/

https://blog.naver.com/adamdoha/222712473510

https://blog.gangnamunni.com/post/understanding_git_flow/

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

https://sihyung92.oopy.io/architecture/gitflow-vs-githubflow