[Git] 2. git-flow 브랜치 전략(개념)

in Devlog on Git



git-flow 브랜치 전략에 대해서 알아보자



6. git-flow 브랜치 전략

todo-app s1

위 그림은 git-flow를 의미합니다. 가장 오른쪽에 있는 파랑색 브랜치가 마스터 브랜치이며, 작업의 흐름을 보면 이 마스터 브랜치에서 분기(branch)된 뒤 최종적으로 다시 마스터 브랜치에 병합(merge)됨을 알 수 있습니다.

master, develop, feature, release, hotfix의 다섯가지 브랜치가 있다.


master

master 브랜치에 merge된 내역은 새로운 버전이 갱신되었다는 것을 의미한다. 즉 master 브랜치에 변경 내역이 최종 버전인 Tag를 통해 Production에 배포된다.


develop

실제 개발이 이루어지는 브랜치이면서 hotfix를 제외한 모든 변경내역이 출발하는 지점이다. develop 브랜치의 코드가 안정화되고 배포할 준비가 되면 master를 통해 배포 버전의 태그를 단다.


feature

todo-app s1

새로운 기능을 개발하기 위해 develop 브랜치에서 feature/xxxxxx 형식으로 분기(feature)해서 기능이 다 완성되면 develop 브랜치로 병합(merge)한다.


release

release 브랜치는 실제 배포할 상태가 된 경우에 생성하는 브랜치다.

개발 완료 후 안정화(일반적으로 QA가 되겠다)를 위한 브랜치이다. 다음 버전에 포함될 기능이 모두 병합(merge)된 시점의 develop 브랜치에서 분기(release)하여 안정화 작업(버그수정)이 끝나면 develop과 master브랜치에 각각 병합(merge)된다.

release 브랜치를 사용하면 안정화를 위한 개발을 하면서도 develop 브랜치나 feature 브랜치에서 지속적으로 개발을 진행할 수 있다.


hotfix

todo-app s1

이미 release 된 소스에서 치명적인 버그가 발견 시 긴급히 수정하여 배포해야할 때 사용하는 브랜치이다.



git-flow의 흐름에 대한 개념을 다음 포스팅에서도 계속 다루기 때문에 한번 스윽~ 읽고 Skip~!

참고