브랜치 전략(git-flow) 정리

 최근 어플리케이션 개발을 거의 마치고 배포 단계에 들어섰는데, 나중에 버전 관리나 배포 자동화를 위해 Git 의 브랜치부터 체계적으로 잡고 가야한다는 생각이 들었다. 그래서 git-flow 전략을 찾아봤고, 프로젝트에 어떻게 적용할 것인지 흐름을 정리해 보고자 한다.

git-flow 의 내용을 설명하기보단 개발 -> 배포까지의 흐름 위주로 정리했다.

develop 브랜치

master 브랜치에서 분기되는 브랜치로, 해당 master 브랜치 버전의 기능 개발을 develop 브랜치에서 하게 된다.

feature 브랜치

develop 브랜치에서 분기되는 브랜치로, 특정 기능을 개발하기 위한 브랜치이다.
feature/{기능} 으로 이름지으며, 기능이 완성되면 develop 브랜치에 병합하고 feature 브랜치는 지운다.

release 브랜치

기능 개발이 어느정도 이루어지고, 정식 배포가 얼마 남지 않았을 때, 테스트를 위해 develop에서 분기하는 브랜치이다.
- 이번 프로젝트에서 release 브랜치를 테스트 브랜치로 두고, release 브랜치에 코드가 푸시되면 테스트 및 빌드 후 테스트 서버에 자동으로 배포되게끔 적용하려 한다.

 정식 배포 기간이 되면 master, develop 두 브랜치에 모두 병합해야 한다. (버전을 태깅해 커밋하면 버전 관리에 용이함)

hotfix 브랜치

release 나 master 브랜치에서 빠르게 고쳐져야 할 사항이 생길 경우 만들고, 수정 후 master, release, develop 모두에 병합해야 한다.

master 브랜치

정식 출시가 되는 브랜치로, 버전이 업데이트 될 때만 병합되어야 한다.
정식으로 릴리즈된 내용을 기록하고, 버전을 관리하는 브랜치이다.

브랜치를 개발 흐름대로 정리해 보았다. 즉,

1. develop 브랜치에서 feature 브랜치로 기능을 개발하고

2. 기능 개발이 완료되면 release 브랜치로 테스트

3. hotfix 브랜치로 오류 수정 후

4. master 브랜치로 정식 출시 까지의 흐름이 된다.



댓글

이 블로그의 인기 게시물

HTML - input file 버튼 꾸미기

HTML - 이미지 미리보기(jQuery 없이)

BOJ - DNA 유사도(2612)