Gitflow 에서 branch 의 종류 설명

참고 링크

 

https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html

[GitHub] Git 브랜치의 종류 및 사용법 (5가지) - Heee's Development Blog

 

이 글은 위 블로그의 정보를 많은 부분 참고했고, 다만 제가 이해하기 편한 언어로 변경 했기 때문에

사용 자료로 부적합할 수 있습니다.

 

 

5 가지 git branch 종류

 

Gitflow Workflow 에서는 제품을 개발 하는 시점부터 운영하는 마지막까지 항상 존재하는 메인 브랜치 (master, develop) 와 일정 기간 동안만 유지되는 보조 브랜치들 (feature, release, hotfix)을 포함하여 총 5가지의 브랜치를 사용한다.

아래는 Gitflow Workflow 방법에서 사용하는 브랜치의 흐름입니다.

 

 

gitflow workflow 모식도

 

Master Branch

 

언제든 제품으로 출시 될 수 있는 브랜치. 배포 (Release) 이력을 관리하기 위해서 사용. 즉, 배포 가능한 상태만을 관리

 

 

Develop Branch

 

다음 출시 버전을 개발하는 브랜치. 기능 개발을 위한 브랜치들을 병합하기 위해 사용. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 master 브랜치에 병합한다. 평소에 이 브랜치를 기반으로 개발을 진행한다.

 

 

Feature Branch

 

기능을 개발하는 브랜치. Feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때 마다, develop 브랜치로부터 분기한다. feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없다. (로컬에서 관리하고 기능개발이 완료된 시점에서 공유하기 때문)

개발이 완료되면 develop 브랜치로 병합하여 다른 사람들과 공유한다. 더 이상 필요하지 않은 feature 브랜치는 삭제하며, 새로운 기능에 대한 'feature' 브랜치를 원격 저장소에 올린다. 이 때 중요한 것은 --no-ff 옵션으로 올리는 것이다. 쉽게 말하면, 병합한 이력도 브랜치에 남겨야 한다는 말이다.

 

Release Branch 

 

이번 출시 버전을 준비하는 브랜치. 배포를 위한 전용 브랜치를 사용함으로써 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능을 계속 개발할 수 있다. 즉, 딱딱 끊어지는 개발 단계를 정의하기에 하주 좋다.

 

develop 브랜치에서 배포할 수 있는 수준의 기능이 모이면 또는 정해진 배포 일정이 되면, release 브랜치를 분기한다. release 브랜치에서 배포 가능한 상태가 되면 (배포 준비가 완료되면), master 브랜치에 병합한다. 배포 가능한 상태란, 새로운 기능을 포함한 상태로 모든 기능이 정상 동작하는 상태이다. 

 

배포를 준비하는 동안 release 브랜치가 병경되었을 수 있으므로 배포 완료 후 develop 브랜치에도 병합한다. 특정 경우를 제외하고는 새로운 기능을 release 브랜치에 직접 병합하지 않는다.

 

 

 

Hotfix Branch

 

출시 버전에서 발생한 버그를 수정하는 브랜치. 배포한 버전에 긴급하게 수정을 해야할 필요가 있을 경우, master 브랜치에서 분기하는 브랜치이다.

 

develop 브랜치에서 분기하지 않는 이유는, 그럴 경우 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기도 어렵기 때문에 바로 배포 가능한 master 브랜치에서 직접 브랜치를 만들어 필요한 부분만 수정한 후 다시 master 브랜치에 병합하여 이를 배포해야 한다.

여기서 주의깊게 봐야할 점은, master 에서 develop 으로 merge 하는 것이 아니라, hotfix 브랜치에서 develop 으로 merge 한다는 점이다.

 

 

Branch 의 전체 흐름