GitHub Flow 이제 알고는 있어야지

오늘 블로그 포스팅에서 다룰 내용은 브랜치 전략 중에 GitHub Flow 전략입니다. 앞전에 제가 TBD에 대해서 소개를 했었습니다. 처음에는 되게 이해하기 어려운 내용들이 많았지만, 이번에는 다른 브랜치 전략을 가져오게 되었습니다. 이번에는 Git Flow가 아닌 GitHub Flow입니다. 어떤 점이 다른지 어느 상황에서 써야 할지에 대해서 한 번 알아보도록 하겠습니다.

 

이전 TBD나 git flow가 궁금하다면? ⬇️

이제 git flow는 그만 TBD를 도입해보자.

Scott Chacon

schacon - Overview

 

github flow 등장

github flow는 기존에 git flow를 사용하는 개발자들이 GitHub에서 사용하기 복잡하고 생각하다고 하여 나온 브랜치 전략입니다. 가장 큰 특징으로는 git flow에 존재하는 hotfix 브랜치나 feature 브랜치처럼 구분을 하지 않습니다. 수시로 배포가 일어나면서 CI와 배포가 자동화된 프로젝트에서 유용합니다.

 

 

github flow 전략은 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로부터 시작됩니다. 이와 같은 특징으로는 체계적인 부분이 전혀 없기 때문에 브랜치 하나에만 의존하게 됩니다. (master, main..) 그러기 때문에 새로운 브랜치를 생성할 때 브랜치 이름이 의도를 명확하게 나타내는 것이 매우 중요하다고 합니다.

 

Master(Main) 브랜치

Master(Main) 브랜치는 항상 stable 한 상태여야 합니다. 

⭐️ stable 하다고?

언제든지 커밋을 하거나 배포를 해도 문제나 결함이 발생하지 않으며, 또 언제든지 새로운 브랜치를 생성해도 문제가 일어나지 않아야 합니다.

이러한 특징으로 Master(Main) 브랜치의 모든 커밋은 빌드가 되고 테스트를 통과해야 하며, 이것이 github flow에 강제하는 유일한 규칙, 사항 중이라고 불릴 수 있다.

 

Topic 브랜치

일명 feature 브랜치라고 불리는 Topic 브랜치는 새로운 기능을 개발할 때 Master(Main)으로 생성하는 브랜치를 뜻한다. 이러한 브랜치는 git flow와 같은 역할을 하지만 앞서 이야기했듯이 별도로 Hotfix 브랜치를 관리하지 않으며 버그 수정도 Topic 브랜치에서 작성한다.

⭐️ 어떻게 해야 효율적으로 Topic 브랜치 이름을 작성할 수 있을까??

example : feature/user-content-login-ID 등등.. 조금 세세하고 하이픈으로 작성을 많이 한다고 합니다.

 

Topic 브랜치의 특징

일반적으로 커밋을 할 때 기능이 완성되지 않았더라도 꾸준하게 push 한다고 합니다. 기능이 끝나야 push 하는 것이 아니라 적절히 개발 중간마다 커밋을 하는 것을 추천한다고 합니다. 이러한 가장 큰 이유는 코드의 유실을 막아주는데 도움이 된다고 합니다. (뭐 이건 개발자, 팀의 차이가 아닐까 싶네요..) 이로써 구성원 모두가 끊임없이 효율적인 커뮤니케이션이 가능하다고 합니다.

 

우리 팀의 프로덕트.. 어떤 브랜치가 좋을까? git flow vs github flow

개발팀이 소규모 애자일 팀이고, 제품이 단일 릴리즈 버전밖에 없다면 git flow가 더 적절하다. 하지만 대부분 많은 웹 애플리케이션은 여러 버전을 관리하지 않고 가장 최신 버전만 주로 관리하는 것이 대부분이다. 아마 github flow는 하루도 많은 변경사항을 작위 단위로 신속하고 자주 병합하고 배포하는 구조는 아마 github flow가 더 적절할 것이다. 즉 github flow는 CI/CD가 자동화가 이뤄진 소규모 팀에서 PR, Action을 통하여 간단하게 전략을 짤 수 있어서 빠르게 도입하기 좋다. 이 정도?

 

 

github flow 같은 경우에는 master(main) 브랜치에 push가 되면 자동으로 배포가 되도록 설정하는 것이 best이다.

 

참고한 자료 중에 가장 간결하고 이해하기 쉬운 reference 공유하겠습니다!!
(출처 : 구글 불곰님)

[Git] 브랜치 전략 - Github flow

 

마치며

아직 프로젝트 팀에서 브랜치 전략을 git flow밖에 사용을 안 해봐서 잘 모르겠다. 만약 여러 릴리즈 버전을 관리한다면? github flow 전략을 사용하지 않을까?라는 생각이 든다. 다음은 gitlab flow이다.