Git 흐름: 전문적인 분기 작업 흐름
힘내 흐름 엄격한 구조를 정의하는 Git의 분기 패턴입니다. 다양한 규모의 프로젝트를 관리하도록 설계된 브랜치입니다. Vincent Driessen, Git Flow 작성 특히 다음과 같은 프로젝트에 적합합니다. 계획된 출시 그리고 일하는 팀 여러 기능을 병렬로 실행합니다.
🎯 무엇을 배울 것인가
- Git Flow의 분기 구조(기본, 개발, 기능, 릴리스, 핫픽스)
- 기능, 릴리스 및 핫픽스를 관리하는 방법
- 명명 규칙 및 모범 사례
- Git Flow와 다른 워크플로우를 사용하는 경우
주요 지점
Git Flow는 프로젝트 수명 동안 유지되는 두 개의 영구 분기를 사용합니다.
메인(또는 마스터):
- 코드만 포함 생산 준비
- 각 커밋은 공식 릴리스입니다.
- 버전 번호(v1.0.0, v1.1.0 등)로 태그됨
- 절대 직접 커밋
개발하다:
- 지점 완성 새로운 기능을 위해
- 최신 개발 현황을 담고 있습니다.
- 기능 분기는 여기에서 시작됩니다.
- 향후 릴리스를 위한 기반
Git 흐름 초기화
# Inizia un nuovo progetto con Git Flow
git flow init
# O manualmente:
git checkout -b develop main기능 분기
I 기능 분기 새로운 기능을 개발하는 데 사용됩니다. 그들은 시작합니다
develop 다시 병합됩니다. develop 완료되면.
워크플로 기능 분기
# Crea un nuovo feature branch
git flow feature start user-authentication
# Equivalente a:
# git checkout -b feature/user-authentication develop
# Lavora sulla feature
git add .
git commit -m "feat: add login form"
git commit -m "feat: add JWT authentication"
git commit -m "test: add auth tests"
# Finisci la feature (merge in develop e cancella il branch)
git flow feature finish user-authentication
# Equivalente a:
# git checkout develop
# git merge --no-ff feature/user-authentication
# git branch -d feature/user-authentication📝 기능 명명 규칙
feature/user-authenticationfeature/payment-integrationfeature/dark-mode- 케밥집을 이용하세요
- 설명적이고 간결한 이름
릴리스 브랜치
I 릴리스 브랜치 프로덕션 환경에서 새 릴리스 준비를 지원합니다.
팀이 진행하는 동안 사소한 버그 수정 및 메타데이터 준비(버전, 빌드 날짜)가 가능합니다.
계속 노력해라 develop.
워크플로 릴리스 분기
# Crea release branch da develop quando le feature sono pronte
git flow release start 1.2.0
# Equivalente a:
# git checkout -b release/1.2.0 develop
# Bug fix e preparazione release
git commit -m "chore: bump version to 1.2.0"
git commit -m "fix: correct typo in welcome message"
git commit -m "docs: update changelog"
# Finisci la release (merge in main E develop, tag su main)
git flow release finish 1.2.0
# Equivalente a:
# git checkout main
# git merge --no-ff release/1.2.0
# git tag -a v1.2.0
# git checkout develop
# git merge --no-ff release/1.2.0
# git branch -d release/1.2.0
# Pusha main, develop e i tag
git push origin main develop --tags⚙️ 릴리스 브랜치에서 해야 할 일
- ✅ 사소한 버그 수정
- ✅ 버전 번호 업데이트
- ✅ 변경 로그 준비
- ✅ 프로덕션 빌드 및 최종 테스트
- ❌ 새로운 기능 (개발하러 가기)
핫픽스 분기
그만큼 핫픽스 브랜치 그들은 프로덕션에서 수정할 수 없는 중요한 버그를 수정하는 것입니다.
다음 릴리스를 기다리십시오. 그들은 시작합니다 main 그리고 다음으로 병합됩니다. main
E develop.
워크플로 핫픽스 분기
# Bug critico in produzione! (main è alla v1.2.0)
git flow hotfix start 1.2.1
# Equivalente a:
# git checkout -b hotfix/1.2.1 main
# Correggi il bug
git commit -m "fix: resolve critical payment bug"
# Finisci l'hotfix (merge in main e develop, tag su main)
git flow hotfix finish 1.2.1
# Equivalente a:
# git checkout main
# git merge --no-ff hotfix/1.2.1
# git tag -a v1.2.1
# git checkout develop
# git merge --no-ff hotfix/1.2.1
# git branch -d hotfix/1.2.1
# Deploy immediato in produzione
git push origin main develop --tags전체 예: 개발 주기
기능 개발부터 생산까지 전체 워크플로를 살펴보겠습니다.
전체 Git 흐름 주기
# Setup iniziale
git flow init
# Crea branch: main, develop
# Sprint 1: Due sviluppatori lavorano su feature diverse
# Developer 1:
git flow feature start shopping-cart
# ... lavoro ...
git commit -m "feat: add cart component"
git flow feature finish shopping-cart
# Developer 2:
git flow feature start user-profile
# ... lavoro ...
git commit -m "feat: add profile page"
git flow feature finish user-profile
# Entrambe le feature sono ora in develop
# Prepara release
git flow release start 1.0.0
git commit -m "chore: bump version to 1.0.0"
git commit -m "docs: update README"
git flow release finish 1.0.0
# main ora è alla v1.0.0, deploy in produzione
# Bug critico trovato in produzione!
git flow hotfix start 1.0.1
git commit -m "fix: cart total calculation error"
git flow hotfix finish 1.0.1
# main ora è alla v1.0.1, hotfix deployato
# Nel frattempo, develop continua con nuove feature
git checkout develop
git flow feature start payment-gateway
# ... sviluppo continua ...Git 흐름 모범 사례
✅ 해야 할 일
- 미국
--no-ff병합용(분기 기록 유지) - 꼬리표 언제나 메인에서 출시
- 설명이 포함된 커밋 메시지 작성(기존 커밋)
- 기능/릴리스를 완료하기 전에 테스트
- Pusha는 정기적으로 개발 및 메인을 진행합니다.
- 완료 전 코드 검토를 위해 Pull Request 사용
❌ 하지 말아야 할 것
- 메인이나 개발에 직접 커밋하지 마세요
- 기능 브랜치를 너무 오랫동안 열어두지 마세요
- 릴리스 브랜치에 새로운 기능을 포함하지 마세요
- 핫픽스를 개발에 병합하는 것을 잊지 마세요
- 지속적 배포를 수행하는 경우 Git Flow를 사용하지 마세요.
명명 규칙
명확한 명명 규칙은 팀이 각 분기의 목적을 이해하는 데 도움이 됩니다.
명명 예
# Feature branches
feature/user-authentication
feature/api-integration
feature/responsive-navbar
# Release branches
release/1.0.0
release/2.1.0
release/3.0.0-beta
# Hotfix branches
hotfix/1.0.1
hotfix/2.1.3
hotfix/security-patch-3.0.1Git Flow를 사용해야 하는 경우
✅ 다음과 같은 경우 Git Flow를 사용하세요.
- 당신은 계획된 출시 (지속적인 배포가 아님)
- 지원 여러 버전 생산 중
- 당신은 훌륭한 팀 많은 병렬 기능을 갖춘
- 안정성을 위해 엄격한 프로세스 필요
❌ 다음과 같은 경우 Git Flow를 피하세요.
- 당신은 지속적인 배포 (GitHub Flow 사용)
- 당신은 소규모 팀 (< 3명)
- 프로젝트가 단순하거나 프로토타입입니다.
- 하루에 여러 번 배포
Git Flow의 대안
Git Flow가 유일한 워크플로우는 아닙니다. 대안은 다음과 같습니다.
- GitHub 흐름: 지속적인 배포를 위해 더 간단하고 기본 + 기능 분기만 제공
- GitLab 흐름: 브랜치 환경을 갖춘 Git Flow와 GitHub Flow 간의 하이브리드
- 트렁크 기반 개발: 모든 사람이 기능 플래그를 사용하여 기본/트렁크에 커밋합니다.
Git 흐름용 도구
Git Flow CLI 설치
# macOS
brew install git-flow
# Linux (Ubuntu/Debian)
sudo apt-get install git-flow
# Windows (Git Bash)
# Download da: https://github.com/petervanderdoes/gitflow-avh
# Verifica installazione
git flow version결론
Git Flow는 예정된 릴리스와 여러 버전을 관리하는 팀을 위한 강력한 워크플로입니다. 생산 중. 엄격한 구조는 규율과 예측 가능성을 제공하지만 지속적인 배포를 수행하는 단순한 프로젝트나 팀에는 과도합니다. 다음과 같은 경우 Git Flow를 선택하세요. 안정성과 체계적인 프로세스가 우선입니다.
🎯 핵심 포인트
- 두 개의 영구 분기: 기본 (생산) 전자 개발하다 (완성)
- 새로운 기능을 위한 기능 브랜치
- 릴리스 준비를 위한 릴리스 브랜치
- 프로덕션의 심각한 버그에 대한 핫픽스 브랜치
- 계획된 릴리스 및 대규모 팀에 적합