22.2: Gitflow 작업 흐름 (workflow)

본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 22.2: Gitflow 작업 흐름 (workflow)

Vincent Driessen 에 의해서 제안된 Gitflow 는 git 과 몇가지 미리 정의된 브랜치들을 이용하는 개발 작업 흐름(workflow) 이다. 이는 Feature 브랜치 작업 흐름(workflow) 의 특수한 케이스로 볼 수 있다.

이 방법의 기본 개념은 개발 진행상에 있어 특정 목적을 위한 별도의 브랜치들을 지정해 놓는 것이다:

• master 브랜치는 항상 가장 최신의 상품화 코드가 존재하는 곳이다. 실험적인 기능 구현 코드는 이 브랜치에 들어가지 않는다.
• develop 브랜치는 가장 최신의 개발 코드 전체를 포함하는 브랜치이다. 이곳에 포함되는 개발 진행 상의 변경사항에는 특별한 제한이 없으나, 비교적 대규모의 기능들은 해당 기능을 위한 별도의 브랜치를 할당하도록 한다 . 이 브랜치의 코드들은 항상 작업의 대상이 되며, 실제 release 나 배포 (deployment) 전에 release 브랜치로 merge 된다.
• hotfix 브랜치들은 다음 릴리즈까지 적용이 지연될 수 없는 작은 버그 수정 등을 위한 브랜치이다. hotfix 브랜치들은 master 브랜치로부터 떨어져 나오게 되며 master 와 develop 두 브랜치에 적용되게 된다.
• release 브랜치들은 develop 브랜치로부터 master 브랜치로 새로운 개발 내역을 release 할때 사용하게 된다. 버전 정보 업데이트 등의 마지막 순간의 변경사항들이 이 release 브랜치에서 이루어지게 되며, 마찬가지로 master 와 develop 브랜치에 다시 merge 되게 된다. 새로운 버전 배포시에는, 이후에 있을 참조 혹은 rollback 편의성을 위해 현재 버전 정보 (예: semantic versioning 을 이용하여) 를 가지고 tag 를 달아 놓는 것이 좋다.
• feature 브랜치들은 상대적으로 대규모의 기능 구현을 위한 브랜치이다. 이러한 기능들은 전용으로 지정된 브랜치에서 개발이 진행되며 개발이 완료되면 develop 브랜치에 통합되게 된다. 이러한 전용 feature 브랜치의 사용은 각 항목별 개발 진행 작업을 분리하며 완료된 기능들이 서로간에 영향을 받지 않고 배포될 수 있는 환경을 제공한다.

도식화된 모델 설명:

도식화된 원본 모델:

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)