GitHub Flow vs Git Flow

개요

---

평소에는 Git Flow만 알고 있었는데, 강의를 통해 GitHub Flow도 있다는 사실을 알았습니다. 따라서 Git Flow와 GitHub Flow를 비교해보고자 합니다. 각 팀의 상황에 따라서 적절한 전략을 선택하는 데 도움이 될 것입니다.

 

 

 

Git-Flow

---

 

 

feature, develop, release, hotfix, master 5가지의 브랜치 전략을 가지고 있습니다.
기능을 개발하기 위해서 feature 브랜치를 만들고, 브랜치를 이동할 때 check out 명령어를 사용하면 됩니다. feature 브랜치는 개발을 동시가 아닌 별도로 진행하여 충돌을 막습니다.

기능 개발이 모두 끝나면, develop 브랜치에 머지합니다. develop 브랜치는 마치 master 브랜치와 비슷합니다. 왜냐하면 아직 released 되지 않은 최신의 소스코드를 유지하기 때문입니다. 만약에 모든 검증이 끝났다면, develop 브랜치로부터 release 브랜치를 만듭니다.

만약에 release 브랜치에서 문제가 발견되었다면, release 브랜치에서 문제를 해결한 후 develop 브랜치로 머지합니다. release 브랜치 코드가 정상 배포되었다면, 최종 코드는 develop과 master 브랜치로 머지합니다. 이 방법으로 matser 브랜치는 항상 운영 환경의 코드를 유지하고, dvelop 브랜치는 개발 환경의 최신 코드를 유지합니다

Git-Flow는 hotfix 브랜치가 있는데, 실제 운영중인 문제를 빠르게 수정하기 위한 것입니다. 문제가 해결되고 나면, develop 브랜치, 그 다음에 master 브랜치로 머지합니다.

 

장점

• 브랜치별로 책임을 명확히 하는 규칙성
• 매우 디테일하게 버전 정보 제공
• master에 있는 코드는 매우 깔끔한 상태 유지(테스트되고 최종 수정된 것만 반영되기 때문)
• 브랜치별로 역할이 있으므로 문제가 있더라도 문제 발생시 각 브랜치를 대기 시킬 필요가 없음(freeze)

단점

• 많은 브랜치 때문에 생기는 복잡한 규칙
• release 로 인한 많은 동기화 작업
• 애자일의 반복적인 접근법과 Git-Flow의 엄격하고 구체적인 규칙과 충돌

 

 

GitHub-Flow

---

Git-Flow와 달리, GitHub-Flow는 release 브랜치가 없습니다. 하나의 버전이 만들어졌으면, 배포될 수 있다는 개념입니다. ithub-Flow는 hotfix가 사소한 기능 변화라고 생각합니다.

 

장점

• 깔끔하고 간단한 협력 규칙
• 지속적인 통합과 개발의 편리함
• 빠른 피드백과 이슈 발행 및 변화를 독려
• feature 개발 이후 dvelop, release까지 전달할 필요가 없음

 

단점

• Git-Flow에 비해 체계적이지 않음. 자유분방한 코드 관리로
• 전체적인 개발 프로세스 관리가 더 힘들어질 수 있음
• 짧은 주기가 아닌 큰 주기의 release의 환경에는 맞지 않음
• 운영과 개발 브랜치 모두를 감당하는 master 브랜치는 코드가 지저분 할 수 있음
• release 준비와 버그 수정이 모두 master 브랜치에 있으므로 특별한 주의가 더 필요함

 

어떤 전략을 사용해야 할까요?

---

 만약에 개발부서가 작은 애자일 조직이고, 각 리포지토리에 제품의 1개의 릴리즈 버전만 배포한다면 GitHub-Flow가 좋습니다. GitHub-Flow는 매우 간단하고 지속적인 개발과 배포에 굉장히 효과적입니다. 새로운 기능과 버그 수정에 확실하고 명료화된 과정들을 제공합니다. 또한 파이프라인을 간소화하면서 전달에 집중합니다.

 

 릴리즈 단위가 크고, 코드를 체계적으로 관리한다면 Git Flow가 좋습니다. release, hotfix 브랜치가 있으면 각 브랜치별로 책임이 명확하기 때문에 이력관리가 쉽습니다.

 

 

Git Flow의 역사 엿보기

---

Git Flow의 사례가 2010년 소개된 이후 ( 링크 ) 정말 많은 조직들이 이 방식으로 git 이력을 관리해왔습니다. 그런데 재미있게도 이를 비판한 글이 10년 후인 2020년에 올라옵니다. ( 링크 ) Git Flow는 이미 많은 레퍼런스 자료가 있는 만큼, 이번에는 이 비판글에 대해서 간략하게 소개하고자 합니다.

 

결론적으로 이를 의식했는지, 2020년 Git Flow 소개 글에서는 아래와 같이 추가 코멘트를 남겼습니다.

 

Git-Flow 소개 저자의 10년 후 추가 첨언

 

만약에 지속적인 배포를 한다면, 더 간단한 모델인 workflow(예를 들어, GitHub flow) 를 추천합니다.

 

 

아래에서는 GitFlow를 향한 비판이 어떤 내용이었는지 한번 살펴보겠습니다. 꽤나 수위가 쎄고 많은 댓글이 달릴만큼 논쟁이 있었던 글입니다. 요악하면, 빠르고 즉각적인 수정과 배포가 이루어져야 하는 웹 어플리케이션 환경에서 복잡한 깃 버전 관리는 불필요하다는 내용입니다. 

 

 

1. GitFlow는 복잡하다

feature, release,master,hotfix,tag까지 엄청나게 많은 브랜치들이 있습니다. 프로젝트를 빌드하고 테스트하기까지 많은 이해과정이 필요합니다

2. GitFlow는 "Short-lived" 브랜치 규칙을 위반한다

dvelop 브랜치로 머지하는 브랜치가 무려 feature, release, hotfix 3개가 있기 떄문에 여러 사람이 작업하는 환경 상, 충돌이 필요 이상으로 많아집니다. 따라서 머지 충돌의 가능성이 기하급수적으로 올라갑니다. 만약에 커밋이 정말 적다면 상관없지만, 스타트업이나 정말 빠른 배포가 필요한 환경에서는 맞지 않습니다.

3.GitFlow는 rebase에 맞지 않다

rebase하면 머지 커밋이 사라집니다.(머지 커밋은 2개의 브랜치가 하나가 되는 지점입니다) gitflow은 시각적으로 복잡하므로, 시각적으로 브랜치를 추적해야하며, 문제를 해결하고 싶다면 rebase를 사용하지 말아야 합니다.

4. GitFlow는 지속적 배포를 불가능하게 만든다

지속적 배포는 자동화된 방법으로 팀이 소스코드를 실제 운영에 반영하는 것입니다. gitflow가 그렇게도 복잡한데 어떻게 지속적인 배포를 할 수 있을지 설명할 수 있을까요? 전체 브랜치 모델들이 긴 주기의 릴리즈 사이클을 가지고 있다면 가능하지만, 몇 분 혹은 몇 시간 단위에는 적합하지 않습니다..

5. GitFlow는 여러 개의 레포지토리에서 작업하는게 불가능하다

마이크로 서비스가 대두되면서, 개인화된 팀들은 자신들의 레포지토리와 작업흐름을 별도로 가집니다. 복잡한 브랜치 모델인 gitflow로 여러개의 팀이 모두 같은 페이지에 있을 수 있을까요? 그럴 수 없습니다. 

어떤 팀이 GitFlow를 사용해야 할까요?

만약에 조직이 1달 혹은 분기별로 release를 하고, 동시에 여러개의 release를 만든다면 Gitflow는 좋은 선택지가 될 수 있습니다. 하지만 만약 조직이 스타트업이고, 웹 어플리케이션 환경이어서 하루에도 여러개의 release를 배포해야 한다면, gitflow는 적절하지 않습니다. 

만약 팀이 10명 이하의 소수이면, gitflow는 오히려 작업의 부하를 더 크게 만듭니다. 반면에, 동시에 여러 release를 만들면서 팀이 20명 이상이라면 gitflow는 좋은 선택입니다

GitFlow를 사용하지 않으면 무엇을 사용해야 하나요?

확답을 할 수 없습니다. 모든 브랜치 모델이 상황에 따라 문화에 따라서 적절한 것은 아니기 때문입니다. 중요한 포인트는 팀에 질문을 하는 것입니다. 이 브랜치 모델이 우리 팀의 어떤 문제를 해결 할 수 있을까요? 이 브랜치 모델이 어떤 문제를 만들까요? 이 모델이 어떤 종류의 개발을 하도록 도울까요? 어떠한 브랜치 전략을 사용하든지 궁극적인 목적은 사람들이 쉽게 소프트웨어를 만들기 위해 서로 협력하는 것입니다. 따라서, 브랜치 모델은 인터넷에서 누군가가 "성공적"이라고 평가하는 방식이 아닌 실제 프로젝트를 수행하는 관련된 사람들의 필요에 맞춰서 정해져야 합니다.

 

 

* 출처

https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/

https://quangnguyennd.medium.com/git-flow-vs-github-flow-620c922b2cbd