Git Branch 전략: Gitflow와 네이밍 규칙의 중요성

 

 

---

개요

Git을 활용한 협업 개발에서 효율적인 코드 관리를 위한 Git Branch 전략은 매우 중요합니다. 다양한 Git 브랜치 전략 중 Gitflow는 특히 팀 단위로 협업하는 프로젝트에서 널리 사용되고 있습니다. 이 포스트에서는 Gitflow 전략과 브랜치 네이밍 규칙에 대해 살펴보겠습니다.

 

Gitflow

Gitflow는 브랜치 기반의 워크플로우로, 각 기능 개발, 버그 수정, 릴리스 등에서 어떤 브랜치를 사용할지 명확히 정의하는 규칙을 제공합니다. Gitflow 전략은 프로젝트 개발의 각 단계별로 명확한 브랜치 규칙을 설정하여 코드 충돌을 최소화하고, 효율적인 협업을 가능하게 합니다.

 

Gitflow 사용하는 이유

• 명확한 역할 구분: 각 브랜치가 맡는 역할이 명확해져 팀원들이 브랜치의 목적을 쉽게 이해하고 협업할 수 있습니다.
• 효율적인 버전 관리: 버전 관리를 명확히 할 수 있어, 여러 기능이 동시에 개발되는 환경에서도 충돌을 최소화할 수 있습니다.
• 배포 준비 및 핫픽스 용이: 릴리스 준비와 긴급 수정 작업이 분리되어 있어 배포 전후의 작업을 효율적으로 처리할 수 있습니다

 

Gitflow의 주요 브랜치

master

항상 배포 가능한 안정적인 상태를 유지하는 브랜치입니다. 제품의 릴리스 버전이 반영됩니다.

 

develop

개발 중인 기능들이 모이는 브랜치입니다. 다음 출시 버전을 개발하는 브랜치로 모든 새로운 기능은 develop 브랜치에서 개발됩니다.

 

feature

새로운 기능을 개발할 때 사용하는 브랜치입니다. develop 브랜치에서 파생되어 해당 기능 개발이 완료되면 develop 브랜치로 병합됩니다.

 

release

새로운 버전의 출시를 준비할 때 사용하는 브랜치입니다. 이 브랜치는 버그 수정과 최종 준비가 완료된 상태에서 develop에서 분기하여 master로 병합됩니다.

 

hotfix

배포된 버전에서 긴급한 수정이 필요할 때 사용하는 브랜치입니다. master에서 분기하여 수정 후 다시 master와 develop에 병합됩니다.

 

 

Gitflow 브랜치 네이밍 규칙

Gitflow에서는 브랜치 이름을 통해 해당 브랜치가 어떤 역할을 하는지 명확하게 구분할 수 있습니다. 명확한 네이밍은 팀원들이 브랜치의 목적을 쉽게 이해하고 혼동을 줄이는 데 도움을 줍니다.

 

master, develop

develop과 master는 기본적인 이름으로 변경하지 않습니다.

 

 

feature

형식: feature/{기능명}

예시: feature/login-page, feature/user-authentication

 

release

형식: release/{ git tag, 릴리즈 버전 }

예시: release/1.0.0, release/2.1.0

 

hotfix

형식: hotfix/{버그번호}

예시: hotfix/fix-login-bug, hotfix/issue-254