Git-flow
Git-flow 는 2010년 Vicent Driessen이라는 분이 만든 가장 널리 알려진 Git 작업 절차로 Git 브랜치 전략중 하나 입니다.
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow 에 따르면
GitFlow는 feature 브랜치와 여러 기본(primary) 브랜치를 사용하는 대안적인 Git 브랜치 모델 입니다.
git-flow는 Vincent Driessen의 branching model을 적용하여 고수준으로 저장소를 관리할 수 있도록 해주는 확장기능입니다.
branching model은 feature - develop - release - hofixes - master 단계로 branch를 나눠서 코드를 관리하는 전략입니다.
- Repositories
- upstream (Upstream Repository) 프로젝트 관리자 계정
- origin (Origin Repository) 내계정
- Branches
- feature : 기능을 개발하는 브랜치
- develop : 다음 출시 버전을 개발하는 브랜치 (origin/develop 에서 관리)
- release : 이번 출시 버전을 준비하는 브랜치
- hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
- master : 기본 브랜치로 제품으로 출시될 수 있는 브랜치 (origin/master 에서 관리)
Git-flow는 총 5가지의 브랜치를 사용해서 운영을 합니다.
- master : 기준이 되는 브랜치로 제품을 배포하는 브랜치 입니다.
- develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합(Merge)칩니다.
- feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합칩니다.
- release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치 입니다.
- hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치 입니다.
항상 유지되는 메인 브랜치들(master, develop)과
일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있습니다.
develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가됩니다.
새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성합니다.
기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 됩니다.
develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성합니다. QA를 진행하면서 발생한 버그들은 release 브랜치에 수정됩니다.
QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 합니다. 마지막으로 출시된 master 브랜치에서 버전 태그를 추가합니다.
Branch naming 규칙
master, develop, release-*, hotfix-*
연관된 글 :
참고 :
https://techblog.woowahan.com/2553/
지속적 통합/배포(CI/CD)를 위한 Git Workflow 전략
https://git.jiny.dev/gitflow/feature
https://dahye-jeong.gitbook.io/git/git/2019-01-27-git-flow
'개발 > 형상관리' 카테고리의 다른 글
| [Git] 소스트리 fatal : Could not read from remote repository. (0) | 2024.06.06 |
|---|---|
| [Git] git (0) | 2023.07.10 |
| commit 메시지 규칙 (0) | 2023.04.11 |
