## πŸ“Œ Brief Summary Git Branching Strategy 및 ν˜‘μ—… μ›Œν¬ν”Œλ‘œμš°λŠ” λ‹€μˆ˜μ˜ κ°œλ°œμžκ°€ ν•˜λ‚˜μ˜ μ½”λ“œλ² μ΄μŠ€μ—μ„œ μ•ˆμ „ν•˜κ³  효율적으둜 ν˜‘μ—…ν•˜κΈ° μœ„ν•œ 체계적인 약속이닀. 브랜치 λͺ…λͺ… κ·œμΉ™, 컀밋 λ©”μ‹œμ§€ ν‘œμ€€ν™”, Pull Request(PR) 기반의 μ½”λ“œ 리뷰 ν”„λ‘œμ„ΈμŠ€λ₯Ό 톡해 μ½”λ“œμ˜ μ•ˆμ •μ„±μ„ μœ μ§€ν•˜κ³  λ³€κ²½ 이λ ₯의 좔적성(Traceability)을 ν™•λ³΄ν•˜λŠ” 것을 λͺ©ν‘œλ‘œ ν•œλ‹€. ## πŸ“– Core Content 1. **μ£Όμš” 브랜칭 μ „λž΅** - **Feature-Branch Workflow**: 짧은 수λͺ…μ˜ 브랜치λ₯Ό 톡해 κΈ°λŠ₯을 격리 κ°œλ°œν•˜κ³  `main`의 μ•ˆμ •μ„±μ„ μœ μ§€ν•˜λŠ” μ†Œκ·œλͺ¨ νŒ€ μ΅œμ ν™” 방식. - **Trunk-Based Development**: 메인 λΈŒλžœμΉ˜μ— 맀우 λΉˆλ²ˆν•˜κ²Œ λ³‘ν•©ν•˜μ—¬ λΉ λ₯Έ ν”Όλ“œλ°±μ„ μΆ”κ΅¬ν•˜λŠ” κ²½λŸ‰ν™” μ „λž΅. - **GitHub Flow**: 지속적 배포에 μ ν•©ν•œ λ‹¨μˆœν•œ ꡬ쑰둜 `main` λΈŒλžœμΉ˜λŠ” 항상 배포 κ°€λŠ₯ μƒνƒœλ₯Ό μœ μ§€ν•œλ‹€. 2. **브랜치 및 컀밋 κ±°λ²„λ„ŒμŠ€** - **λͺ…λͺ… κ·œμΉ™**: `{type}/{ticket-id}-{description}` ν˜•μ‹μ„ μ€€μˆ˜ν•˜μ—¬ μž‘μ—…μ˜ 성격과 λΉ„μ¦ˆλ‹ˆμŠ€ λ§₯락(ν‹°μΌ“ ID)을 μ—°κ²°ν•œλ‹€. - **Conventional Commits**: `feat:`, `fix:`, `refactor:` λ“± ν‘œμ€€ 접두사λ₯Ό μ‚¬μš©ν•˜μ—¬ λ³€κ²½μ˜ μ˜λ„λ₯Ό λͺ…ν™•νžˆ ν•˜κ³  릴리즈 λ…ΈνŠΈλ₯Ό μžλ™ν™”ν•œλ‹€. - **μ›μžμ  컀밋 (Atomic Commits)**: ν•˜λ‚˜μ˜ μ»€λ°‹μ—λŠ” ν•˜λ‚˜μ˜ 논리적 λ³€κ²½λ§Œ λ‹΄μ•„ λ‘€λ°± 및 디버깅을 μš©μ΄ν•˜κ²Œ ν•œλ‹€. 3. **Pull Request(PR) 및 μ½”λ“œ 리뷰** - μ΅œμ†Œ 1λͺ… μ΄μƒμ˜ μŠΉμΈμ„ κ±°μΉ˜λŠ” κ²Œμ΄νŠΈμ›¨μ΄ ν”„λ‘œμ„ΈμŠ€λ₯Ό κ΅¬μΆ•ν•œλ‹€. - **Squash Merge**: κΈ°λŠ₯ 브랜치의 μžμž˜ν•œ 이λ ₯을 μ••μΆ•ν•˜μ—¬ 메인 브랜치의 νžˆμŠ€ν† λ¦¬λ₯Ό κΉ”λ”ν•˜κ²Œ κ΄€λ¦¬ν•œλ‹€. - **CI 연동**: PR 생성 μ‹œ λΉŒλ“œ 및 ν…ŒμŠ€νŠΈ μžλ™ 톡과λ₯Ό ν•„μˆ˜ 쑰건으둜 μ„€μ •ν•œλ‹€. ## βš–οΈ Trade-offs & Caveats - **속도 vs μ•ˆμ •μ„±**: μ—„κ²©ν•œ PR 리뷰와 브랜칭 μ „λž΅μ€ μ•ˆμ •μ„±μ„ λ†’μ΄μ§€λ§Œ, κΈ΄κΈ‰ν•œ 배포가 ν•„μš”ν•œ μƒν™©μ—μ„œλŠ” 병λͺ© 지점이 될 수 μžˆλ‹€. - **수λͺ…이 κΈ΄ 브랜치의 μœ„ν—˜**: 메인 λΈŒλžœμΉ˜μ™€ μž₯μ‹œκ°„ λ™κΈ°ν™”λ˜μ§€ μ•Šμ€ λΈŒλžœμΉ˜λŠ” 병합 μ‹œ 'λ¨Έμ§€ μ§€μ˜₯(Merge Hell)'을 μœ λ°œν•˜λ―€λ‘œ μž¦μ€ λ¦¬λ² μ΄μŠ€μ™€ 동기화가 ν•„μˆ˜μ μ΄λ‹€. - **컀밋 μ••μΆ•μ˜ 정보 μ†Œμ‹€**: Squash MergeλŠ” νžˆμŠ€ν† λ¦¬λ₯Ό κΉ¨λ—ν•˜κ²Œ λ§Œλ“€μ§€λ§Œ, κΈ°λŠ₯ 브랜치 λ‚΄λΆ€μ˜ 세뢀적인 κ²°μ • 과정을 μΆ”μ ν•˜κΈ° μ–΄λ ΅κ²Œ λ§Œλ“€ 수 μžˆλ‹€. ## πŸ”— Knowledge Connections ### Related Concepts (Auto-Linked) * [[Git Hooks]] * [[GitHub Actions]] * [[GitHub Flow]] * [[GitLab CI]] * [[Husky]] * [[Research]] * [[Strategy]] ### Related Concepts - **Pull Request (PR)**: μ½”λ“œ ν’ˆμ§ˆμ˜ μ΅œμ’… κ΄€λ¬Έ (관계: μ‹€μ²œ ν”„λ‘œμ„ΈμŠ€) - **Conventional Commits**: λ³€κ²½ 이λ ₯의 ν‘œμ€€ν™” (관계: 컀밋 κ°€μ΄λ“œλΌμΈ) - **Trunk-Based Development**: 고속 반볡 κ°œλ°œμ„ μœ„ν•œ μ „λž΅ (관계: λŒ€μ•ˆ 방법둠) ### Deeper Research Questions 1. ν‹°μΌ“ ID(Jira/GitHub)와 Git 컀밋을 μ—°λ™ν•˜μ—¬ 개발 진척도λ₯Ό μžλ™μœΌλ‘œ λŒ€μ‹œλ³΄λ“œν™”ν•˜λŠ” 졜적의 CI 섀정은? 2. 'Merge'와 'Rebase' 쀑 νŒ€μ˜ νžˆμŠ€ν† λ¦¬ 관리 철학에 따라 μ–΄λ–€ 것을 κΈ°λ³Έ μ „λž΅μœΌλ‘œ μ‚Όμ•„μ•Ό ν•˜λŠ”κ°€? 3. λŒ€κ·œλͺ¨ μΆ©λŒμ„ λ°©μ§€ν•˜κΈ° μœ„ν•΄ Feature Flagλ₯Ό λ„μž…ν•˜μ—¬ 수λͺ…이 κΈ΄ 브랜치λ₯Ό Trunk-Based둜 μ „ν™˜ν•˜λŠ” ꡬ체적인 μ ˆμ°¨λŠ”? 4. μ½”λ“œ 리뷰 μ‹œ 기술적 결함 외에 μ•„ν‚€ν…μ²˜μ  일관성을 κ²€μ¦ν•˜κΈ° μœ„ν•œ '체크리슀트'의 ꡬ성 μš”μ†ŒλŠ” 무엇인가? 5. 컀밋 λ©”μ‹œμ§€ κ·œμΉ™ μ€€μˆ˜λ₯Ό κ°•μ œν•˜κΈ° μœ„ν•΄ Git Hooks(Husky)와 commitlintλ₯Ό μ—°λ™ν•˜λŠ” 졜적의 ν™˜κ²½ ꡬ성은? ### Practical Application Contexts - **νŒ€ ν˜‘μ—… ν‘œμ€€ν™”**: 3인 이상 νŒ€ ν”„λ‘œμ νŠΈ μ‹œμž‘ μ‹œ 브랜칭 μ „λž΅κ³Ό 컀밋 μ»¨λ²€μ…˜ ν•©μ˜ 및 λ¬Έμ„œν™”. - **이슈 좔적성 κ°•ν™”**: μž₯μ•  λ°œμƒ μ‹œ νŠΉμ • ν‹°μΌ“ ID와 μ—°κ΄€λœ 컀밋을 μ—­μΆ”μ ν•˜μ—¬ κ·Όλ³Έ 원인 신속 νŒŒμ•…. ### Adjacent Topics - **CI/CD Pipeline Automation** - **GitHub Actions / GitLab CI** - **Semantic Versioning (SemVer)**