Branch 전략
Last updated
Last updated
개발자들이 협업하고 소프트웨어를 개발하는데 사용되는 브랜치 전략 및 워크플로우
main (제품 출시 버전)
develop (다음 출시를 위한 통합 브랜치)
feature (새 기능 개발)
release (출시를 준비하는 브랜치)
hotfix (긴급 버그 수정)
브랜치가 너무 많다!
이를 개선하기 위해 간소화된 Github Flow가 나옴
Github에서 깃을 잘 관리하기 위해 만든 flow
main (항상 배포 가능한 상태를 유지)
기능 추가 및 버그 수정을 위해 새로운 브랜치를 만들고, 작업이 끝나면 main으로 통합
릴리즈 관리는 태깅을 통해 수행
단순하고 직관적
지속적인 배포에 용이
소규모 팀의 애자일 및 지속적 개발에 적합
작은 변경사항을 빠르게 배포
Github Action 자동화 용이 (적은 브랜치, 단순해서)
쉬운 롤백
빠른 사용자 피드백
대규모 프로젝트의 복잡성 다루기
다양한 팀, 의존성 등을 다루기엔 너무 단순함
독립적인 기능을 구현하기 어려움
코드 충돌 가능성 높음
잦은 배포는 롤백이 복잡해짐
브랜치 생성
새로운 기능 및 버그 수정은 main 브랜치에서 새로운 브랜치 생성
코드 작업
Pull Request
main (계속해서 배포 가능한 상태를 유지)
새로운 기능과 버그 수정과 같은 작업은 새로운 브랜치에서 시작하여 개발
main 브랜치로 병합하기 전 Merge Request 생성
코드가 main 으로 머지되면 자동으로 배포 파이프라인 실행
QA를 어느 브랜치에서 할 것인가?
병렬적인 개발을 위한 브랜치 전략은?
