Git-flow
Git-flow는 5가지 종류의 branch가 존재한다. 항상 유지되는 메인 브랜치(master, develop)와 일정 기간동안만 유지되는 보조 브랜치들(feature, release, hotfix)로 구분지을 수 있다.
master: 제품으로 출시될 수 있는 브랜치develop: 다음 출시 버전을 개발하는 브랜치- 즉, 다음 릴리즈를 위해 언제든 배포될 수 있는 상태를 말한다.
feature: 기능을 개발하는 브랜치release: 이번 출시 버전을 준비하는 브랜치- release 준비 시작 후, 다음 feature를 개발 완료한
develop로부터 안전한 release를 보장하기 위해 사용하는 브랜치
- release 준비 시작 후, 다음 feature를 개발 완료한
hotfix: 배포 버전에서 생긴 문제로 긴급한 트러블 슈팅이 필요할 때 개발이 진행되는 브랜치develop과 독립적으로 production에서 발생한 문제를master에서 처리하기 위해 사용하는 브랜치
개발자들이 개발해야 하는 기능은 자신의 로컬에 브랜치를 따로 생성하여 개발을 진행하고, 로컬 브랜치에서 개발이 완료되면 완료된 소스를 develop 브랜치에 push하거나 PR(Pull Request)을 보내 내부적인 코드 리뷰 후 merge 하는 것을 통해 개발이 진행된다.
만약 내가 “로그인/로그아웃”기능을 개발해야 한다면, remote의 devlop 브랜치로부터 로그인/로그아웃 기능을 위한 브랜치를 내 로컬에 생성하여 개발을 진행한다. 이 기능 개발을 위해 생성한 브랜치가 feature 브랜치이다.
중간에 개발이 진행되며 무수히 많은 커밋 메시지를 남길 것이고, 개발이 완료되면 remote의 develop 브랜치로 merge를 하며 이 브랜치는 삭제된다.
hotfix 브랜치는 배포 후 문제가 발생한 것을 확인하여 긴급 수정이 필요할 때 사용되는 브랜치이다.
실제 배포된 master 브랜치가 있고, 이후 개발이 지속적으로 진행된 develop 브랜치가 있다고 할 때, 배포된 버전에서 버그를 발견하였다고 가정해보자. 이 때 develop에서는 배포를 하지 않은 기능이 적용되어 있기 때문에 해당 브랜치는 사용하면 안된다. 그렇기 때문에 master 브랜치에서 새로운 hotfix 브랜치를 따고, 문제가 생긴 코드를 고쳐 master에 merge를 진행한다.(수정된 이 브랜치는 develop에도 적용이 되어야 한다)
release 브랜치는 QA로 넘어가는 소스라고 생각하면 될 것 같다. 요구되는 기능을 모두 개발하고, 배포 전 마지막 테스트를 거치는 소스가 저장되는 브랜치이다. 만약 QA중 문제가 발생하면 해당 브랜치에서 버그픽스를 진행하고 버그가 제거된 release소스는 다시 devlop 브랜치에 적용해야 한다.
release브랜치에서 추가적인 기능 개발을 위해 소스 수정을 진행해서는 안된다.
정리
브랜치가 많기 때문에 관리해야 하는 부담도 늘어났지만 일관되게 여러 상황을 대처 할 수 있게 되었다. 하지만 gitflow는 만능이 아니다. 주로 versioning 기반으로 정기적으로 배포되는 시스템에서 깔끔한 Git 관리를 하기 위해 사용된다는 점을 유의하자.
참고 자료 :
