


구분 | git flow | github flow |
개요 | 다섯 개의 브랜치를 중심으로 다양한 시나리오에 대처 가능한 브랜칭 전략 | main 브랜치와 feature 브랜치만을 두고, 항상 배포되는 main 브랜치를 중심으로 한 브랜칭 전략 |
언제 필요했어? | 서로 다른 배포주기를 가진 기능들이 있을 때
단순한 flow로 인해 다양한 상황에 대처하기 어려웠을 때 | 기능이 빠르게 베이스 브랜치에 병합될 필요가 있을 때
최신 기능이 항상 배포되어도 되는 환경일 때
CI / CD가 잘 갖춰져 있어 버그에 대한 대비가 잘 되어있을 때 |
장점 | 다양한 시나리오(롤백, 핫픽스, 운영배포 등)에 쉽게 대처 가능
서로 다른 배포시기를 가진 코드가 잘 못 딸려나갈 걱정이 없음 | 항상 코드가 최신 상태라는 심리적 안정감
기능 구현 시나리오가 단순하여 편리함 |
단점 | 별도의 배포관리자를 두어야 함
다양한 브랜치를 관리하며 쓸데 없는 머지 커밋이 많이 생김 | 배포 시기가 다른 코드가 딸려나가는 경우가 생김
배포가 자동화 되어 있지 않으면 자주 배포해야 하여 번거로움 |
구분 | 도구 |
배포 관리 시스템 | 쿠버네티스 |
배포 도구 | 젠킨스 |
프로젝트 아키텍처 | 도메인 별로 module을 두어 MSA 구축 |
버전 컨트롤 | gitlab 사용, 모든 코드를 한 개의 레포지토리에서 관리 |
배포 환경 | 개발 - 프론트엔드와 함께 확인할 수 있는 개발 환경
베타 - 사내 다른 모듈도 연동하여 QA를 진행 가능한 베타 환경
운영 - 소비자와 직접 접촉하는 프로덕션 환경 |

