반응형
브랜치 전략
- 여러 개발자들이 협업하는 환경에서 효과적으로 개발하기 위한 Git 사용 전략
대표적인 Git 브랜치 전략
- Github Flow
- master 브랜치를 중심으로 운영
- 기능 개발, QA(Quality Assurance) 등의 작업용 브랜치를 구분하지 않는 구조
- 작업 브랜치에서 master 브랜치로 PR을 한 후 테스트를 하여 검증 후 master 브랜치로 병합
- 브랜치 전략이 단순하여 처음 접하기 쉬움
- Git Flow
- 개발, QA, 운영의 단계를 나눈 브랜치 전략
Github Flow
메인 브랜치
master
기능 개발이 완료된 브랜치들을 병합하는 브랜치
보조 브랜치
feature
목표로 하는 기능을 개발에 사용하는 브랜치
- 근원 브랜치
- master
- 병합할 브랜치
- master
Git Flow
2개의 메인 브랜치와 3개의 보조 브랜치로 구성
메인 브랜치
메인 브랜치는 항상 유지
master/production
출시를 위해 사용되는 브랜치
- 사용 전략
- 운영에 문제가 생길만한 버그가 발생할 경우 hotfix 브랜치를 생성하여 버그를 수정합니다.
- 새로 merge되는 경우 git의 tag 를 이용하여 버전을 명시한다.
develop
다음 버전을 위해 개발하는 브랜치
- 사용 전략
- feature 또는 release 브랜치에서 추가적인 개발이 생긴 경우 merge commit을 생성하여 병합한다.
보조 브랜치
보조 브랜치가 메인 브랜치로 머지가 되면 보조 브래치는 삭제
feature
기능을 개발하는 브랜치
- origin
- develop
- destination
- develop
release
develop브랜치에서 기능 개발이 끝나고 난 후 QA(Quality Assurance)를 위해 사용하는 브랜치
- origin
- develop
- destination
- master/production
- [develop]
- 사용 방법
- release브랜치에서 오류가 생길 경우 release 브랜치에서 수정 후 develop 브랜치에도 병합해준다.
- release브랜치에서는 기능 개발을 진행하지는 않는다.
hotfix
출시 버전에서 발생한 버그를 수정하는 브랜치
- origin
- master/production
- destination
- develop
- master/production
- 사용 방법
- hotfix 브랜치에서 수정된 사항을 develop브랜치와 master브랜치 각각에 병합해준다.
회고
- 프로젝트 초기의 빠른 개발과 피드백이 필요한 상황이라면 Github Flow을 사용하는것이 적합할것이다.
- 프로젝트의 기능 개발이 완성된 후, 운영과 함께 추가적인 기능 개발이 필요한 상황이라면 Git Flow가 적합할것이다.
함께 볼만한 자료
반응형