git은 개발자들의 협업의 도구이지만 집단, 프로젝트의 성격 에 따라서 git을 사용하는 방식은 천차만별이다.
개인적인 프로젝트를 할 때는 일반적으로 두가지 종류의 branch를 가진다.
- Master : 깃허브와 연결된 기준이 되는 로컬브랜치
- Feature : 하나의 기능을 만들 때 마다 생성되는 브랜치
실재 서비스를 할 때는 협업과 배포에 최적화된 5개의 브랜치를 만들고, 이 브랜치들의 유기적인 활용을 git flow라고 한다.
Master
Feature branch
Develop branch
Release branch
Hotfix branch
Develop branch
개발의 기준이 되는 브랜치로, 개인적인 프로젝트에서 활용하는 master 브랜치의 역할을 한다. 기존의 프로젝트에서 master 브랜치를 기준으로 feature 브랜치를 만들었다면, git flow에서는 develop 브랜치를 기준으로 feature 브랜치를 만든다.
Master branch
그렇다면 master 브랜치는 git flow에서 어떤역할을 할까?
개발은 develop브랜치를 기준으로 이루어지고 실재로 배포가 될 코드를 마스터 브랜치에 넣어둔다. 개발은 개발대로 이루어지고 배포가 된 코드는 master에 넣어두어 개발의 흐름이 끊이지 않도록 한다.
master 브랜치에는 실재 배포용 코드가 들어가기 때문에 충분한 검증을 거치게 되고, 배포용대로 따로 관리 되기 때문에 한 팀에서 배포를 해도 다른 팀은 개발을 멈추지 않고 commit을 할 수 있다.
Release branch
배포용 브랜치이며 master브랜치와 다른점은 배포 테스트용으로 사용된다. 즉, master브랜치에는 실재 배포가 된 코드가 들어가고 release 브랜치에는 배포하기전에 상태를 테스트하는 배포 후보 코드가 들어간다.
일반적으 배포 이전에 develop브랜치를 기준으로 release 브랜치를 만들고 테스트를 진행한다. 우선 테스트용 서버에 프로젝트를 올리고 버그가 생기면 release 브랜치를 만들어서 고치는 것이다. release 브랜치에서 생긴 버그를 release 브랜치 안에서 해걸하기 때문에 develop 브랜치(개발의 기준이 되는 브랜치) 에 영향을 주지 않게 된다. 버그가 수정되면 마스터브랜치로 merge, 배포가 되고, develop 브랜치에서 merge가 된다.
그리고 release브랜치는 사용된 이후에는 삭제 한다.
Hot fix branch
실재로 서비스중인 코드(master 브랜치의 코드)에서 문제가 발생하면 hot fix 브랜치를 만들어 버그고치고 검증과정을 거친 이후, 다시 master 브랜치에 merge하고 배포한다. 그리고 develop 브랜치에서도 수정사항을 merge 해준다. 문제가 해결된 이 후에는 hot fix브랜치를 삭제해준다.
이렇게 5개의 브랜치가 유기적으로 필요에 따라 생성되고 삭제된다. 배포와 개발을 분리해서 개발은 멈추지 않고, 검증된 코드를 배포하는 것이 목적이다.
