docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
# [[GitHub Flow]]
|
||||
# [[GitHub Flow|GitHub Flow]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
GitHub Flow는 복잡한 Git Flow의 대안으로 사용되는 가볍고 단순한 브랜치 기반 워크플로우입니다 [1, 2]. 이 방식은 항상 배포 가능한 상태(deployable)를 유지하는 `main` 브랜치를 중심으로 작동하며, 개발자는 새로운 작업을 위해 짧은 주기의 기능 브랜치(feature branch)를 생성합니다 [3-5]. 변경된 코드는 동료의 코드 리뷰와 CI/CD 테스트를 모두 통과한 후 오직 Pull Request(PR)를 통해서만 `main`에 병합됩니다 [1, 6].
|
||||
@@ -25,18 +25,18 @@ GitHub Flow는 복잡한 Git Flow의 대안으로 사용되는 가볍고 단순
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술 (개발 워크플로우)]
|
||||
- [[Git Flow]]
|
||||
- Git Flow
|
||||
- 연결 이유: GitHub Flow와 자주 비교되는 분기 전략으로, 프로젝트의 복잡성에 따라 두 전략 사이를 마이그레이션하는 경우가 많습니다 [2, 12].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: `develop`, `release`, `hotfix` 브랜치를 사용하는 Git Flow를 이해함으로써, 상대적으로 GitHub Flow가 생략한 구조적 복잡성과 그에 따른 속도/단순성의 이점을 명확히 비교할 수 있습니다.
|
||||
- [[Trunk-Based Development]]
|
||||
- Trunk-Based Development
|
||||
- 연결 이유: 소규모 팀에서 빠르고 충돌 없는 병합을 위해 도입할 수 있는 또 다른 경량 워크플로우입니다 [3, 16].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 극단적으로 짧은 생명주기의 브랜치를 사용하거나 메인에 빈번히 직접 병합하는 철학을 통해 CI(지속적 통합)의 본질을 더 깊게 이해할 수 있습니다.
|
||||
|
||||
#### [관계 유형 B: 구현/활용 도구]
|
||||
- [[Pull Request]]
|
||||
- [[풀 리퀘스트 (Pull Request)|Pull Request]]
|
||||
- 연결 이유: GitHub Flow에서 코드 병합을 수행하고 팀원 간의 협업 및 리뷰를 진행하는 가장 핵심적인 메커니즘입니다 [8, 10].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드 품질 통제, 피어 리뷰(Peer Review)의 역할 및 CI/CD 훅(Hook)이 작동하는 방식을 구체적으로 이해할 수 있습니다.
|
||||
- [[CI/CD]]
|
||||
- [[CI_CD|CI/CD]]
|
||||
- 연결 이유: `main` 브랜치를 항상 배포 가능한 상태로 유지하기 위해 배후에서 코드를 검증하는 필수 자동화 파이프라인입니다 [1, 6].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 왜 수동 병합이 위험한지, PR 리뷰가 끝난 코드가 어떻게 안전하게 프로덕션 레벨까지 배포되는지의 전 과정을 파악할 수 있습니다.
|
||||
|
||||
@@ -55,9 +55,9 @@ GitHub Flow는 복잡한 Git Flow의 대안으로 사용되는 가볍고 단순
|
||||
- **My Project Relevance:** 3~5명의 소규모 팀에서 충돌을 최소화하면서도 빠른 피드백과 릴리스가 필요한 현재 프로젝트 상황에, 불필요한 절차를 없애고 안정성을 보장하는 가장 이상적인 협업 모델로 적용할 수 있습니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Conventional Commits]]
|
||||
- Conventional Commits
|
||||
- 확장 방향: 커밋 메시지를 `feat:`, `fix:`, `chore:` 등의 규격으로 통일함으로써, PR 내용의 가독성을 높이고 향후 릴리스 노트를 자동화하는 방향으로 지식을 확장할 수 있습니다.
|
||||
- [[Issue Tracking System]]
|
||||
- Issue Tracking System
|
||||
- 확장 방향: 코드 구현(GitHub)과 요구사항 정의(JIRA, Linear 등)를 연결하여 프로젝트 관리 수준을 높이고 변경 사항의 비즈니스 맥락(Traceability)을 추적하는 방법론으로 확장됩니다.
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user