본문 바로가기
git

git flow vs github flow

by marble25 2024. 1. 27.

이번에 배포 프로세스를 변경하면서 github flow에서 변형 git flow를 사용해 보게 되었다. 이 둘의 차이점을 공부한 김에 정리해두고자 한다.

1. Git Flow

Git flow는 Vincent Drissen이 2010년 그의 블로그에 올린 A Successful Git branching model이라는 글이 인기를 끌면서 대중적으로 사용되기 시작한 브랜치 전략이다.

크게 두 가지 종류의 브랜치가 존재한다.

  • Long living branch: master(main), develop
  • Short living branch: feature, release, hotfix

Master(main) 브랜치

Production으로 나간 코드를 모아놓은 브랜치이다. 여기에 존재하는 코드는 QA가 완료되고, 출시 가능한(또는 출시된) 상태의 코드이다.

Develop 브랜치

개발 단계에 있는 코드를 모아놓은 브랜치이다. 개발이 완료된 시점에 메인 브랜치로 머지된다.

TIP) github을 이용하는 경우 default 브랜치를 develop으로 변경하면 trunk되는 default 브랜치가 develop으로 된다.

Feature 브랜치

개발자 각각이 작업하는 브랜치이다. develop 브랜치에서 생성하여 여기서 작업한 후 Pull Request를 거쳐 develop로 머지되게 된다.

Release 브랜치

배포를 준비하기 위한 브랜치이다. develop 브랜치에서 생성하여 배포 전 사소한 버그를 수정하는데 사용된다. 작업이 완료된 후 develop 브랜치와 master 브랜치 모두에 머지된다.

Hotfix 브랜치

이미 배포된 버전에 문제가 발생한 경우를 위한 브랜치로, main 브랜치에서 생성하여 버그를 수정한 후 develop 브랜치와 main 브랜치에 모두 머지된다.

2. Github flow

Git flow가 널리 사용된 후에 git flow 단점이 부각되었다.

가장 큰 단점은 너무 복잡하다는 것이다. 초기 설정이 복잡하고, 팀원들이 이해하고 따르기 어렵다.

그 대안으로 여러 브랜칭 전략이 나왔는데 가장 대표적인 Github flow를 보자.

Github flow는 master(main) 브랜치와 feature 브랜치 2가지 종류의 브랜치만 존재한다.

모든 변경사항은 main 브랜치에서 시작한 feature 브랜치에서 작업하며, 메인으로 머지만 되면 자동화된 CI/CD를 통해 배포되기 때문에 비교적 짧은 배포 주기를 가진다.

3. Github flow → Git flow

우리 팀은 간단한 개발 사이클과 지속적인 배포를 가능하게 하는 Github flow를 사용해 왔다.

하지만 버전 관리 측면에서 단순히 main 브랜치에 태그를 달아 버저닝을 하는 것으로는 관리가 되지 않았다. 뿐만 아니라 AWS code pipeline을 trigger할 때 단순 tag를 추가하는 이벤트로는 code star를 trigger할 수 없었고(v1 type의 코드 파이프라인을 사용하기 때문에), 브랜치에 명시적인 commit이 발생해야 했다.

이에 Github flow만으로는 불편함을 느꼈고, 좀 더 세밀한 컨트롤이 가능한 Git flow로 전환을 해보게 되었다.

다만 original git flow와 다른 점은 다음과 같다.

  1. release 브랜치가 존재하지 않는다: release 과정에 필요한 커밋은 feature 브랜치에서 작업 후 develop 브랜치에 머지된다.
  2. develop에서 main으로 바로 머지된다: develop → main pull request를 통해 main에 머지된다. 이때, 머지 전략은 rebase를 사용해서 main과 develop이 동일한 커밋 히스토리를 가지도록 한다.

AWS Code star connection은 개발 환경은 develop 브랜치, 운영 환경은 main 브랜치의 변경을 감지하여 trigger된다. 자동화된 Smoke e2e test가 존재하여 develop → main으로 바로 머지되는 것의 위험을 어느 정도 상쇄한다.

변경하고 나니 명확하게 어디까지 운영 환경에 배포되었는지 한 눈에 파악이 가능했고, 자동화된 CD도 가능했다.

'git' 카테고리의 다른 글

[후기] Sapling 써보기  (0) 2023.11.05
graphite 사용기  (2) 2023.10.23
[TIL] Git Server  (0) 2022.05.15
Git 내부 동작 방식 알아보기  (0) 2022.05.07