Git-flow
Git-flow는 브랜치를 크게 4가지로 나누어 개발하는 전략이다.
- 메인 브랜치(Main branch)
- 피쳐 브랜치(Feature branch) 또는 토픽 브랜치(Topic branch)
- 릴리스 브랜치(Release branch)
- 핫픽스 브랜치(Hotfix branch)
가장 중심이 되는 브랜치는 master와 develop 브랜치이다.
merge된 feature, release, hotfix 브랜치는 삭제하도록 한다.
메인 브랜치(Main branch)
master 브랜치와 develop 브랜치를 보통 메인 브랜치로 사용하고 이 두 브랜치를 병행으로 유지한다.
- master
- 배포 가능한 상태만을 관리하는 브랜치
- develop
- 다음에 배포할 것을 개발하는 브랜치
- 통합 브랜치의 역할을 하며 평소에는 이 브랜치를 기반으로 개발을 진행
보조 브랜치(Supporting branch)
피처 브랜치(feature branch) 또는 토픽 브랜치(topic branch)
갈라져 나온 브랜치 : develop
다시 merge 할 브랜치 : develop
이름 규칙 : master, develop, release-, hotfix- 를 제외한 것
- 기능을 개발하는 브랜치로 develop 브랜치로부터 분기
- 그 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merge
- 보통 개발자 저장소에만 있는 브랜치이고 origin 에는 push 하지 않는다
develop 브랜치와 feature 브랜치
- 기존에 잘 작동하는 개발 코드(develop 브랜치)와 새로 변경될 개발 코드(feature 브랜치)를 분리하고 각각 보존하는 것
- feature 브랜치는 Git-flow 전략에서 지칭하는 단위 개발 브랜치의 의미를 갖는다
릴리즈 브랜치(Release branch)
갈라져 나온 브랜치 : develop
다시 merge 할 브랜치 : develop, master
이름 규칙 : release-*
- develop 브랜치에 이번 버전에 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성
- 배포를 위한 최종적인 버그 수정 등의 개발을 수행
- 배포 가능한 상태가 되면 master 브랜치로 병합, 출시된 master 브랜치에 버전 태그 추가
- release 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 develop 브랜치에도 적용해 주어야 한다. 배포 완료 후 develop 브랜치에 대해서도 merge 작업을 수행
핫픽스 브랜치(Hotfix branch)
갈라져 나온 브랜치 : master
다시 merge 할 브랜치 : develop, master
이름 규칙 : hotfix-*
- 배포한 버전에서 긴급하게 수정을 해야 할 때, 마스터 브랜치에서 분기하는 브랜치
- 버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 계속 할 수 있다
- 이 때 만든 hotfix 브랜치에서의 변경 사항은 develop 브랜치에서도 merge하여 문제가 되는 부분을 처리해 주어야 함
Github-flow
Git-flow가 깃헙에서는 사용하기 복잡하다고 하여 나온 브랜칭 전략이다. 흐름이 단순한 만큼 role도 단순하다. 마스터 브랜치에 대한 role만 정확하다면 나머지 브랜치들에 대해서는 관여하지 않는다. 즉, hotfix 브랜치나 feature 브랜치를 구분하지 않는다. pull request 기능을 사용하도록 권장한다.
수시로 배포가 일어나며 CI와 배포가 자동화되어 있는 프로젝트에 유용하다.
사용법
- master 브랜치는 어떤 때든 배포가 가능하다
- 마스터 브랜치는 항상 최신 상태이며, stable한 상태로 product 에 배포되는 브랜치
- 엄격한 role과 함께 사용
- merge 전에 충분한 테스트를 거쳐야 한다.
- master 에서 새로운 일을 시작하기 위해 브랜치를 만든다면 이름을 명확히 작성하자
- 브랜치는 항상 마스터 브랜치에서 만든다
- feature 브랜치나 develop 브랜치가 존재하지 않는다
- 새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해 주도록 한다
- 커밋메세지를 명확하게 작성한다
- 원격지 브랜치로 수시로 push 한다
- 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
- 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다
- 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때에는 pull request를 생성한다
- pull request는 코드 리뷰를 도와주는 시스템이다
- 자신의 코드를 공유하고 리뷰를 받는다
- merge 준비가 완료되었다면 master 브랜치로 반영을 요구한다
- 기능에 대한 리뷰와 논의가 끝난 후 master 로 merge 한다
- master로 merge 되고 push 되었을 때는, 즉시 배포되어야 한다
- Github-flow 의 핵심이다
- 마스터로 merge 가 일어나면 자동으로 배포가 되도록 설정해 놓는다
개발자꿈나무🌲