GIT(Git branch 전략_git flow, github flow)

Git branch 전략

Git branch 전략은 프로젝트의 Git branch를 효과적으로 관리하기 위한 워크플로우이다. 직접 branch 전략을 만들어 사용해도 되겠지만, 세상에는 branch를 효과적으로 관리하기 위한 모범 사례들이 존재한다. 그 모범사례 중에서 유명한 Git Flow, Github Flow가 있다.

---

Git Flow

Git Flow는 네덜란드 빈센트 트라이센(Vincent Driessen) 블로그에서 유래된 branch 전략이다. 

 

Git Flow는 크게 5개의 branch 를 만들어 상호 운영되는 전략이다. 각 branch 는 고유의 기능이 있다. 일부 branch는 병합을 통하여 지속적으로 유지되는 branch도 있다.

• Master
• Develop
• Feature
• Release
• Hotfix

Git Flow는 구분하여 branch를 관리한다. 

Main 브랜치
Develop 브랜치
Supporting 브랜치 ➡️ Feature 브랜치 / Release 브랜치 / Hotfix 브랜치

---

Main 브랜치와, Develop 브랜치는 개발 프로세스 전반에 걸쳐 항상 유지되는 branch이다.

반면, Supporting branch는 필요할 때마다 생성되고, 역할을 다하면 삭제된다. Supporting branch 덕분에 팀이 병렬적으로 업무를 할 수 있게된다.

 

 

Main branch
Main branch는 출시 가능한 프로덕션 코드를 모아두는 branch이다. Main branch는 프로젝트 시작 시 생성되며, 개발 프로세스 전반에 걸쳐 유지된다. 배포된 각 버전을 Tag를 이용해 표시해둔다.

Develop branch
다음 버전 개발을 위한 코드를 모아두는 branch이다. 개발이 완료되면, Main branch로 머지된다.

Feature branch
하나의 기능을 개발하기 위한 branch이다. Develop branch에서 생성하며, 기능이 개발 완료되면 다시 Develop branch로 머지된다. 머지할때 주의점은 Fast-Forward로 머지하지 않고, Merge Commit을 생성하며 머지를 해주어야 한다. 이렇게해야 히스토리가 특정 기능 단위로 묶이게 된다.

네이밍은 feature/branch-name 과 같은 형태로 생성한다.

Release branch
소프트웨어 배포를 준비하기 위한 branch이다. Develop branch에서 생성하며, 버전 이름 등의 소소한 데이터를 수정하거나 배포전 사소한 버그를 수정하기 위해 사용된다. 배포 준비가 완료되었다면 Main과 Develop branch에 둘다 머지한다. 이때, Main branch에는 태그를 이용하여 버전을 표시한다.

Release branch를 따로 운용함으로써, 배포 업무와 관련없는 팀원들은 병렬적으로 Feature branch에서 이어서 기능을 개발할 수 있게된다.

네이밍은 release/v1.1 과 같은 형태로 생성한다.

Hotfix branch
이미 배포된 버전에 문제가 발생했다면, Hotfix branch를 사용하여 문제를 해결한다. Main branch에서 생성하며, 문제 해결이 완료되면 Main과 Develop branch에 둘다 머지한다.

Release branch와 마찬가지로 Hotfix branch를 따로 운용함으로써, 핫픽스 업무와 관련없는 팀은 병렬적으로 기능 개발을 할 수 있다.

네이밍은 hotfix/v1.0.1 과 같은 형태로 생성한다.

---

📌 Git Flow의 한계

• Git Flow가 전형적인 소프트웨어 개발의 프로세스를 따르기 때문에 대형 프로젝트에는 매우 적합한 모델이다.
  하지만 모든 개발 프로세스 공정을 따라 가기에는 시간이 많이 걸리는 단점이 있다.
• Git Flow는 명시적으로 버전관리가 필요한 이를 테면, 스마트폰 어플리케이션, 오픈소스 라이브러리/프레임워크 등의 프로젝트에 적합하다. 유명한 글인 우아한형제들 기술 블로그에 우린 Git-flow를 사용하고 있어요 글을 작성한 팀도 안드로이드 앱 개발팀이다. 웹 어플리케이션은 특성상 사용자는 항상 최신의 단일 버전만을 사용하게된다. 여러 버전을 병렬적으로 지원할 필요가 없는 것이다. 또한 웹 어플리케이션은 하루에 몇번이고 릴리즈될 수 있다. 이런 특성상 웹 어플리케이션 개발에 Git Flow는 다소 적합하지 않다.

---

Github Flow

깃허브의 운영자 스캇 샤콘(Scott Chacon)이 발표한 새로운 브랜치 전략이다. 깃 플로우는 인기 있지만, 자신의 서비스인 깃허브에 응용하기에는 다소 복잡하다고 생각했고, 깃 플로우를 전략을 좀 더 단순하게 하여 빠른 개발 프로세스를 확보하기를 원했다. 이를 위해 깃허브에서 고안된 깃허브 플로우(Github-Flow) 브랜치 전략이 있다.

 

Github Flow는 2개의 branch만 이용한다. 좀 더 단순한  branch 전략을 구성하여 빠른 개발과 배포 환경을 구축할 수 있다.

• Master 
• Feature 

기본적으로 마스터  branch는 배포를 유지하는  branch입니다.

새로운 기능은 feature에 작업하여 master로 병합합니다.

 

Github Flow의 장점은  branch 수가 적기 때문에 빠르게 작업이 가능합니다. 원본 branch에 결합하여 쉽게 배포할 수 있는 장점이 있습니다.

 

 

참고🖇️

https://hudi.blog/git-branch-strategy/

https://git.jiny.dev/gitflow/branch.html

https://gogojuni.dev/gitflow-workflow/