docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
Antigravity Agent
@@ -1,4 +1,4 @@
|
||||
# [[Branching Strategies]]
|
||||
# [[Branching Strategies|Branching Strategies]]
|
||||
|
||||
## 📌 Brief 소Summary
|
||||
Branching Strategies(브랜칭 전략)는 소프트웨어 개발 과정에서 코드 변경 사항을 관리하고 팀원 간의 협업을 조율하기 위해 버전 관리 시스템(Git 등)에서 브랜치를 생성, 병합, 유지보수하는 규칙과 워크플로우를 의미합니다. 팀의 규모와 프로젝트 요구사항에 따라 Git Flow, GitHub Flow, Trunk-Based Development, Feature Branch Workflow 등 다양한 전략이 사용됩니다. 명확한 브랜칭 전략의 도입은 메인 코드베이스의 안정성을 보장하고 병합 충돌을 방지하며 코드 리뷰와 추적성을 강화하는 핵심 역할을 합니다 [1-3].
|
||||
@@ -29,21 +29,21 @@ Branching Strategies(브랜칭 전략)는 소프트웨어 개발 과정에서
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 방법론]
|
||||
- [[Feature Branch Workflow]]
|
||||
- Feature Branch Workflow
|
||||
- 연결 이유: 소규모 3~5인 개발 팀에 가장 추천되는 단순하고 직관적인 브랜칭 전략의 기반 개념입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 메인 브랜치를 오염시키지 않고 새로운 기능을 격리된 환경에서 개발하고 병합하는 방법론을 이해할 수 있습니다.
|
||||
- [[Trunk-Based Development]]
|
||||
- Trunk-Based Development
|
||||
- 연결 이유: 무거운 워크플로우를 탈피하여 브랜치 생명주기를 극한으로 줄이고 빠른 통합을 중시하는 최신 트렌드 모델입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: CI/CD 환경에서의 잦은 소규모 배포 방식과 충돌 최소화 전략을 학습할 수 있습니다.
|
||||
- [[Git Flow]]
|
||||
- Git Flow
|
||||
- 연결 이유: 브랜칭 전략의 고전적이고 체계적인 형태로서, 대형 프로젝트의 정기적 버저닝 관리를 위해 설계되었습니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: `develop`, `release`, `hotfix` 등 개발 파이프라인에 따른 브랜치의 역할 분리 기법을 이해할 수 있습니다.
|
||||
|
||||
#### [관계 유형 B: 구현/활용 도구 및 규칙]
|
||||
- [[Pull Request & Code Review]]
|
||||
- Pull Request & Code Review
|
||||
- 연결 이유: 브랜칭 전략이 안전하게 동작하기 위해 모든 병합 전에 필수적으로 거쳐야 하는 품질 검증 관문입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀원 간의 비동기적 피드백 수렴, 시각적 검증, 그리고 CI 통과를 전제로 한 안전한 병합 과정을 배울 수 있습니다.
|
||||
- [[Conventional Commits]]
|
||||
- Conventional Commits
|
||||
- 연결 이유: 브랜치 병합 내역을 추적하고 가독성을 높이기 위해 전 세계적으로 통용되는 커밋 메시지 작성 표준입니다.
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: `feat(scope): message` 와 같은 형식의 구문을 통해 코드 히스토리 파악 및 문서 자동화를 어떻게 이룰 수 있는지 이해할 수 있습니다.
|
||||
|
||||
@@ -62,9 +62,9 @@ Branching Strategies(브랜칭 전략)는 소프트웨어 개발 과정에서
|
||||
- **My Project Relevance:** 3~5인 규모의 프로젝트에서 무거운 Git Flow의 도입을 지양하고, '단기 기능 브랜치 → PR 및 1인 이상 피어 리뷰 승인 → Squash Merge 및 브랜치 즉시 삭제'라는 단순화된 룰을 적용하여 개발 속도와 코드 품질을 동시에 챙깁니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Continuous Integration / Continuous Deployment (CI/CD)]]
|
||||
- Continuous Integration / Continuous Deployment (CI/CD)
|
||||
- 확장 방향: 브랜칭 전략에 의해 트리거(Trigger)되어 실행되는 빌드, 테스트, 배포 파이프라인의 자동화 프로세스를 깊이 알아봅니다.
|
||||
- [[Feature-Sliced Design (FSD)]]
|
||||
- [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD)]]
|
||||
- 확장 방향: 도메인과 기능 단위로 코드를 분리하는 프론트엔드 아키텍처 방법론으로, 브랜치를 기능별로 나눌 때 충돌을 물리적으로 최소화하는 코드 구조 설계법을 탐구합니다.
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user