[Git 브랜치 전략] Git-flow
Git 브랜치 전략은 말그대로 주로 협업에서 Git의 branch기능을 적극 활용하여 업무를 관리하는 일종의
방법론으로 생각하시면 됩니다. 그 중 대표적인 ‘Git-flow’방식에 대해 간단히 정리해보도록 하겠습니다.
참고한 블로그는 다음과 같습니다.
1. Git-flow 전체 구성도 및 각 Branch 요약
우선 전체적인 Git-flow의 브랜치 기본 흐름 구성은 다음 그림과 같습니다.
(팀에 따라 중간에 test브랜치 등을 추가하는 등 여러 수정이 있을 수 있습니다.)
그리고 각 Branch의 기록대상을 요약하면 다음과 같습니다.
master : 공식 배포, 릴리즈 커밋내역 브랜치 (각 커밋에 버전 태그를 붙여 관리합니다.)
hofix : 릴리즈 이후 예상치 못한 버그, 요구사항에 대한 빠른 패치작업을 진행하는 브랜치
release : 기능 개발 완료 이후 공식 배포를 준비하는 브랜치 (버그픽스, 설명서 추가 등)
develop : 기능 개발 관리 및 통합 브랜치
feature : 실제 기능 개발 작업 브랜치
2. Git-flow Branch 생성 흐름
기본적인 생성, 통합 흐름을 요약하면 다음과 같이 진행됩니다.
master → develop 생성, 푸쉬 → feature 생성 및 작업 → feature 심사 및 develop에 병합
→ release 생성 및 작업 → develop, master에 release 병합 (배포 준비 끝)
→ 배포 후 문제 발생 → hofix 생성 및 작업 → develop, master에 병합
==================================================================================
develop : master에서 분기
feature : develop에서 분기 - develop에 병합
release : develop에서 분기 - develop, master에 병합 후 삭제
hofix : master에서 분기 - develop, master에 병합 후 삭제
master브랜치의 경우 위에서 언급한 대로 각 통합 버전명을 태그로 붙이고, feature나 release의 경우
팀에 따라 여러 방법이 있지만 보통 다음과 같이 /로 구분하여 기능이나 버전을 작성해 명명합니다.
git branch feature/기능
git branch release/버전
주의할 점은 feature에서 기능작성을 완료한 뒤 바로 master로 병합되는 것이 아니라 develop에 통합되
release를 거치는 이런 단계를 여러 팀원과의 혼선을 최소화 해야합니다.
언제나 읽어주셔서 감사합니다.^^
개인 공부용 블로그입니다.
잘못된 부분에 언제든지 댓글이나 메일로 지적해주시면 감사하겠습니다.
Leave a comment