git flow, github flow, trunk-based development
git flow에서 기능 개발은 feature 브랜치에서 이루어지고, 완료 후 develop 브랜치에 병합됨. 릴리스를 준비할 땐 release 브랜치를 따로 만들어 QA와 최종 검증을 거친 뒤, 프로덕션 코드를 관리하는 main에 병합하게 됨.
만약 긴급한 수정 사항이 발생 시, hotfix 브랜치를 만들어 신속히 배포하고, 수정 사항을 develop엣도 반영함
git flow를 이용하면 대규모 프로젝트에서 굉장히 체계적이고 안정적인 관리가 가능하지만, 브랜치가 많아짐에 따라 복잡도가 올라간다는 단점
github flow는 git flow보다 단순한 구조
모든 변경 사항은 main 브랜치 기준
새로운 기능 개발할 때 feature 브랜치를 생성한 뒤 작업 끝나면 코드 리뷰를 받고 바로 main에 병합
이 방식은 간소화된 프로세스를 가지고 있기 때문에 짧은 주기의 배포 환경에서 특히 유용
하지만 릴리스와 QA를 위한 별도의 브랜치가 없어서 안정성 관리가 중요한 프로젝트에는 다소 부담스러울 수 있음
trunk-based development는 main(또는 trunk) 브랜치 하나만 운용하는 방식
작업을 main 브랜치에 직접 커밋하거나, feature 브랜치를 만들고 며칠 내에 빠르게 병합
병합 주기가 짧아 코드 충돌 가능성이 적다는 장점
but 철저한 자동화 환경이 뒷받침되어야 한다는 단점이 존재
git flow vs github flow
프로젝트 상황에 맞는 전략을 선택할 것
git flow - 릴리스 주기가 길고 qa가 중요한 프로젝트에서 사용하기 적합
ex - 금융 서비스처럼 안정성과 품질이 중요한 프로젝트에선 git flow 적합
github flow 자주 배포 이뤄지고 변경 사항 빠르게 반영해야 하는 스타트업과 유사한 환경에서 유리
