Git Workflow 전략 비교

https://inpa.tistory.com/entry/GIT-⚡️-github-flow-git-flow-📈-브랜치-전략

https://devocean.sk.com/blog/techBoardDetail.do?ID=165571&boardType=techBlog

https://projectlog.tistory.com/59

https://ksh-coding.tistory.com/109

Gitflow

구조

• master : 라이브 서버에 제품으로 출시되는 브랜치. release 브랜치로부터 pr을 받는다.
• develop : 다음 출시 버전을 대비해 개발하는 브랜치. 특정 단계까지 구현이 왼료되면 release 브랜치를 만들어 검수한다.
• feature : 특정 단위 기능을 개발하는 브랜치. 기능 구현이 완료되면 develop 브랜치에 pr을 보낸다.
• release : 배포 이전에 제품을 QA, 테스트하는 브랜치. 테스트가 정상적으로 완료되면 develop 브랜치와 master 브랜치에 각각 pr을 보낸다.
• hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치. 버그 수정이 완료되면 master 브랜치와 develop 브랜치에 각각 pr을 보낸다.

특징

• 기능 추가가 필요할 때 Feature 브랜치를 만들어 개발한 후 Develop 브랜치로 병합한다.
• 배포 준비가 완료되면 Release 브랜치를 생성해 추가 테스트 및 수정 작업을 진행하고, 완료되면 Main과 Develop 브랜치에 병합한다.
• 수정이 필요할 경우 Hotfix 브랜치에서 작업 후 main과 develop에 병합한다.

단점

• 여러 브랜치를 사용하기 때문에 소규모 프로젝트나 빈번한 배포가 필요한 경우 다소 복잡할 수 있다.
• 자동화된 배포 프로세스를 사용하는 경우 단순한 브랜치 전략이 더 유리할 수 있다.