[Git] Git 브랜칭 전략(1) Git-flow

📌 이번 글은

Git 브랜칭 전략 1탄 Git-flow 정리입니다.

 

 

Git 브랜칭 전략이란?

Git 브랜치를 효과적으로 나누고, 관리하는 전략

 

 

Git-flow

• 브랜치를  5가지로 나누어 개발하는 전략
• (1) feature (2) develop (3) release (4) master (5) hofix

Git-flow 한눈에 보기

(1) feature

• 기능 구현을 담당하는 브랜치.
• 브랜치명 : feature/{구현기능명}로 지정.
  ex) feature/login 은 login 기능을 구현하는 브랜치.
• feature 브랜치는 develop 브랜치에서 생성되고, develop 브랜치로 merge 됩니다.
• feature 브랜치는 보통 개발자 저장소에만 있고, origin에는 push 하지 않습니다.
• merge 된 후에 해당 브랜치는 삭제합니다.

 

(2) develop

• 다음 배포 내용 개발을 진행하는 중심적인 브랜치.
• 하나의 feature 브랜치가 머지될 때마다, develop 브랜치에 해당 기능이 더해지며 살을 붙여갑니다.
• develop 브랜치는 배포할 수준의 기능을 갖추면 release 브랜치로 merge 됩니다.

 

(3) release

• 개발된 내용을 배포하기 위해 준비하는 브랜치.
• 브랜치명 : release-1과 같이 브랜치 순서 지정.
• release 브랜치에서 테스트 -> 버그 검사 -> 버그 수정을 진행합니다.
• 배포할 준비가 완전히 되었다고 판단되면 master로 merge 합니다. (이때, master 브랜치에 버전 태그를 추가.)
• release 브랜치는 develop 브랜치에서 생성되고, 버그 수정 내용은 develop 브랜치에도 merge 해야 합니다.

 

(4) hotfix

• 배포된 소스에서 버그가 발생하면 생성되는 브랜치.
• 브랜치명: hotfix-1과 같이 브랜치 순서 지정.
• master 브랜치에서 발견되는 버그들에 대해서 수정하는 브랜치.
• hotfix 브랜치는 master 브랜치에서 생성되고, 수정이 완료되면 master 브랜치에 merge 됩니다.
• 수정 사항은 develop 브랜치, release 브랜치에도 merge 해야 합니다.

 

(5) master 브랜치

• 배포 가능한 상태만을 관리하는 가장 중심적인 브랜치.

 

 

Git-flow 특징

• Git-flow 브랜치 전략은 여러 브랜치들이 각 브랜치마다 역할이 명확하게 분류되어 있으나, 오히려 많은 브랜치가 흐름을 복잡하게 만들 수 있습니다.
• 또한 어떤 프로젝트에 따라서는 몇몇 브랜치가 애매한 포지션을 가질 수 있습니다.
• 그러나 주기적으로 배포를 해야 하는 프로젝트에 적합하고, 프로젝트의 규모가 커지면 소스코드를 관리하기에 용이합니다.

 

 

이어지는 포스팅

[Git] Git 브랜칭 전략(2) Github-flow

 

 

🙋🏻‍♀️ 참고

git 브랜치 전략에 대해서

Git 브랜칭 전략 : Git-flow와 Github-flow