Git Flow에서 Github Flow로의 전환
주제 요약
- 브랜치 전략의 선택과 변경의 필요성 및 도입 배경을 설명합니다.
- 브랜치 전략 변경 후 느낀 것을 설명합니다.
기존 main, develop, feature로 이루어진 Git Flow 전략에서 main, feature로 이루어진 Github flow로의 전환이 이루어진 이유입니다.
모노레포이므로 FE와 BE 모두 하나의 Git 저장소에 저장됩니다. 따라서 각 프로젝트가 독립적으로 개발되더라도, 하나의 main 브랜치로 배포를 관리하는 것이 더 효율적이라고 판단되었습니다.
짧은 기간안에 기능을 개발하고 배포를 해야합니다. 따라서 feature 브랜치에서 바로 main 브랜치로 병합하는 전략을 통해 각 기능을 빠르게 피드백하고 짧은 배포 주기를 유지하는 것이 중요하다고 판단되었습니다.
주요 브랜치:
- master: 항상 안정적인 상태를 유지하는 브랜치, 프로덕션에 배포된 버전.
- develop: 개발 중인 코드가 반영되는 브랜치.
- feature: 새로운 기능 개발을 위한 브랜치.
- release: 배포 준비를 위한 브랜치, 개발이 완료되면 master와 develop에 병합.
- hotfix: 배포된 버전에서 발견된 버그 수정.
Git Flow의 특징:
- 복잡한 프로젝트나 팀 단위 개발에서 유용.
- 다양한 브랜치를 관리하므로 브랜치가 많아져 관리가 복잡해질 수 있음.
- 배포 주기가 길거나 여러 버전을 동시에 관리할 때 적합.
주요 단계:
- main: 항상 프로덕션 상태인 안정적인 브랜치.
- feature branch: 새로운 기능이나 버그 수정을 위한 브랜치, main에서 분기.
- Pull Request(PR): 개발이 완료되면 feature branch에서 main 브랜치로 PR을 생성.
- Review & Merge: PR 리뷰 후 main 브랜치에 병합.
GitHub Flow의 특징:
- 간단하고 직관적이며, 작은 팀과 빠른 배포에 적합.
- 매번 main 브랜치에 바로 변경 사항을 병합하는 방식으로, CI/CD 파이프라인과 잘 결합.
- 개발 주기가 짧고, 여러 기능을 병렬적으로 진행하며 작은 변경을 자주 배포할 때 유리.
(점선이 merge를 의미한다)
각 브랜치의 역할 :
-
main: 자동 배포 걸어두는 브랜치. 버전업 시에만 merge하여 반영한다. -
develop: feature 브랜치를 묶는 브랜치. 완성한 feature 브랜치들을 develop으로 merge시킨다. -
feature: 기능 단위 개발을 위한 브랜치. 가장 하위 레벨이다.
기존 Git Flow에서 main, develop, feature 브랜치를 차용하여 브랜치 전략을 설계하였습니다.
각 브랜치 및 단계:
-
main: 자동 배포 걸어두는 브랜치. 버전업 시에만 merge하여 반영한다. -
feature: 기능 단위 개발을 위한 브랜치. 가장 하위 레벨이다. -
Pull Request: 기능 개발 완료시 feature branch에서 main 브랜치로 PR 생성 -
Review & Merge: : PR 리뷰 후 main 브랜치에 병합합니다.
feature에서 개발한 기능의 PR을 리뷰 후 main 브랜치에 merge합니다.
Github Flow로 변경한 후 다음과 같은 장점을 느낄 수 있었습니다.
작업 충돌 가능성이 줄어들었으며, 코드 리뷰와 병합 과정이 간소화되어 짧은 배포 주기를 유지할 수 있었고, 이를 통해 빠르게 개발과 배포를 할 수 있었습니다.
모노레포 환경에서 develop 브랜치를 유지하기 위해 모든 프로젝트 상태를 조율해야하는 부담감을 줄일 수 있었습니다.