[G1-Sync] Manual knowledge update

2026-05-10 22:08:15 +09:00
parent 21ac3ed255
commit 504fd5fb42
3011 changed files with 380280 additions and 206977 deletions
@@ -4,87 +4,152 @@ title: Version Control Systems
 category: 10_Wiki/Topics
 status: verified
 canonical_id: self
-aliases: [P-REINFORCE-WIKI-DEV-VCS, 버전 관리, VCS, Git, 형상 관리, 소스 제어]
+aliases: [VCS, Source Control, SCM]
 duplicate_of: none
 source_trust_level: A
-confidence_score: 1.0
-tags: [VCS, Git, Collaboration, Engineering_History, Context]
-raw_sources: [Datacollector_Export_2026-05-02]
-last_reinforced: 2026-05-02
+confidence_score: 0.95
+verification_status: applied
+tags: [git, vcs, devops, collaboration]
+raw_sources: []
+last_reinforced: 2026-05-10
 github_commit: pending
+tech_stack:
+  language: shell
+  framework: git
 ---

-# [[버전 관리 시스템과 엔지니어링 컨텍스트 (Version Control Systems)]]
+# Version Control Systems

-## 1. 개요
-버전 관리 시스템(Version Control System, VCS)은 소스 코드의 시간적 변화를 기록하고 관리하는 기술적 기반이다. 단순히 코드의 백업이나 협업 도구를 넘어, 특정 설계가 선택된 이유, 과거의 시도와 실패 사례, 비즈니스 요구사항과의 연결 고리를 담고 있는 프로젝트의 '살아있는 역사서'이자 핵심적인 엔지니어링 컨텍스트의 원천이다.
+## 매 한 줄
+> **"매 source-of-truth + time machine + collaboration substrate"**. VCS 는 코드 변경 history 를 content-addressable 하게 저장하여 branching/merging/rollback 의 atomic 단위 제공. 매 2026 현재 Git (DVCS) 이 90%+ 시장 — Mercurial, Pijul, Jujutsu (jj) 가 niche 로 존재.

-## 2. 주요 역할과 가치
- **설계 의도의 보존**: 커밋 메시지와 풀 리퀘스트(PR) 설명은 코드가 현재 상태로 작성된 배경과 의사결정 과정을 기록한다.
- **협업 및 충돌 관리**: 분산된 개발자들이 동일한 코드베이스에서 동시에 작업할 수 있도록 브랜치 전략과 병합(Merge) 메커니즘 제공.
- **추적 가능성 (Traceability)**: 특정 코드 라인이 언제, 누구에 의해, 어떤 목적으로 변경되었는지 추적하여 버그의 기원이나 아키텍처적 변천사 파악.
- **지식 자산화**: 이슈 트래커와 연동된 PR 기록은 문서화되지 않은 암묵적 지식을 명시적 지식으로 전환하여 팀의 인지적 자산을 형성함.
+## 매 핵심

-## 3. 효과적인 활용 전략
- **의미 있는 커밋 단위**: '무엇'을 변경했는지가 아닌 '왜' 변경했는지를 설명하는 명확한 커밋 메시지 작성.
- **PR 중심의 컨텍스트 구축**: 상세한 PR 설명, 관련 이슈 링크, 코드 리뷰 과정의 토론 기록을 통해 미래의 분석가를 위한 단서 제공.
- **히스토리 분석을 통한 해독**: 낯선 코드를 만났을 때 `git blame`과 관련 PR을 역추적하여 현재 코드의 제약 사항과 설계 의도를 파악.
+### 매 Architecture 분류
+- **Centralized (CVCS)**: SVN, Perforce — single server, lock-based 또는 merge-based.
+- **Distributed (DVCS)**: Git, Mercurial — 매 clone 이 full history 보유.
+- **Modern alternatives**: Pijul (patch theory), Jujutsu (Git-compatible, snapshot-based UX).

-## 4. 트레이드오프 및 주의사항
- **정보 과부하**: 방대한 커밋 이력 중 무의미한 수정(오타 수정, 컨벤션 변경 등)이 섞여 있을 경우 핵심 의도를 파악하는 효율이 떨어짐.
- **기록의 파편화**: 커밋 메시지가 부실하거나 PR 설명이 누락된 경우, VCS는 단순한 파일 저장소로 전락하며 과거의 지식을 복구하기 힘들어짐.
- **대규모 Diff의 위험**: 한 번의 PR에 너무 많은 파일 변경이 포함될 경우 리뷰 품질이 저하되고 나중에 히스토리를 분석할 때 맥락 파악이 어려워짐.
+### 매 Git internals
+- **Object model**: blob (file), tree (directory), commit (snapshot+parent), tag (named ref).
+- **DAG**: commits 가 parent pointer 로 directed acyclic graph 형성.
+- **Refs**: `.git/refs/` 의 branches/tags 가 commit hash 의 movable pointer.
+- **Index (staging)**: working tree 와 commit 사이의 transition zone.

-## 5. 지식 연결 (Related)
- [[Git_History_Analysis]]: VCS 데이터를 분석하여 인사이트를 도출하는 기법.
- [[Pull_Request_Review]]: VCS 상에서 이루어지는 협업의 핵심 프로세스.
- [[Technical_Debt]]: VCS 이력 분석을 통해 식별할 수 있는 아키텍처적 부채.
+### 매 응용
+1. Source code collaboration (GitHub, GitLab, Bitbucket).
+2. Infrastructure-as-Code (Terraform, Kubernetes manifests) versioning.
+3. Documentation (Docs-as-Code, MkDocs/Docusaurus).
+4. ML model + dataset versioning (DVC, Git-LFS, lakeFS).
+5. Database schema migrations (Flyway, Liquibase + Git).

-## 🧪 검증 상태 (Validation)
- **정보 상태**: 검증 완료 (Verified)
- **출처 신뢰도**: A
- **검토 이유**: 소프트웨어의 현재 모습 이면에 숨겨진 엔지니어링 의사결정의 맥락을 보존하고 활용하기 위한 형상 관리 표준 정립.
+## 💻 패턴

-## 📌 한 줄 통찰 (The Karpathy Summary)
+### Trunk-based development
+```bash
+# Short-lived feature branch (< 24h), continuous merge to main
+git checkout -b feat/payment-retry
+# ... small commits ...
+git rebase main
+git push -u origin feat/payment-retry
+gh pr create --base main
+# After review, squash-merge → delete branch
+```

-> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
+### Atomic commit + Conventional Commits
+```bash
+git commit -m "feat(auth): add OIDC token refresh

-## 📖 구조화된 지식 (Synthesized Content)
+- Refresh 5min before exp
+- Exponential backoff on 5xx
+- Closes #1423"
+```

-**추출된 패턴:**
-> *(TODO)*
+### Bisect for regression hunt
+```bash
+git bisect start
+git bisect bad HEAD
+git bisect good v2.4.0
+# Git checkouts mid-commit; run test
+git bisect run pnpm test:integration
+# → Prints first bad commit
+git bisect reset
+```

-**세부 내용:**
- *(TODO)*
+### Worktrees for parallel branches
+```bash
+git worktree add ../proj-hotfix hotfix/cve-2026-1234
+cd ../proj-hotfix
+# Independent working tree, shared .git
+```

-## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
+### Reflog rescue
+```bash
+# Accidentally reset --hard?
+git reflog
+# 7a3f2b1 HEAD@{2}: commit: WIP feature
+git reset --hard HEAD@{2}
+```

-**언제 이 지식을 쓰는가:**
- *(TODO)*
+### Signed commits (supply chain)
+```bash
+git config user.signingkey ~/.ssh/id_ed25519.pub
+git config gpg.format ssh
+git config commit.gpgsign true
+# Commits now signed; GitHub shows "Verified" badge
+```

-**언제 쓰면 안 되는가:**
- *(TODO)*
+### Jujutsu (jj) workflow — 매 modern alternative
+```bash
+jj init --git-repo .
+jj new -m "WIP refactor"
+# Edit files; no staging, no add
+jj describe -m "feat: extract payment service"
+jj git push --branch main
+```

-## 🧬 중복 검사 (Duplicate Check)
+### LFS for large binaries
+```bash
+git lfs install
+git lfs track "*.psd" "*.bin"
+git add .gitattributes *.psd
+git commit -m "chore: track design assets via LFS"
+```

- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
+## 매 결정 기준
+| 상황 | Approach |
+|---|---|
+| Open source / distributed teams | Git + GitHub/GitLab |
+| Monolithic large repo (game studios, AAA) | Perforce (Helix Core) — large binary handling |
+| Patch-theory cherry-picking heavy | Pijul |
+| Stacked diffs / phabricator-style | Jujutsu (jj) or Sapling (Meta) |
+| Compliance / audit-heavy | Git + signed commits + branch protection rules |

-## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
+**기본값**: Git + trunk-based development + Conventional Commits + signed commits + GitHub Actions CI.

- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
+## 🔗 Graph
+- 부모: [[Software-Engineering]] · [[Collaboration-Tools]]
+- 변형: [[Git]] · [[Mercurial]] · [[Perforce]] · [[Jujutsu]] · [[Pijul]]
+- 응용: [[GitOps]] · [[CI-CD]] · [[Code-Review]] · [[DVC-ML-Versioning]]
+- Adjacent: [[Monorepo-Tools]] · [[Branch-Strategies]] · [[Conventional-Commits]]

-## 🔗 지식 연결 (Graph)
+## 🤖 LLM 활용
+**언제**: commit message 작성, PR description, conflict resolution 설명, git history archaeology.
+**언제 X**: force-push 결정, branch protection policy 설계 — 매 human judgment 필요.

- **Parent:** [[10_Wiki/Topics]]
- **Related:** *(TODO: 최소 2개)*
- **Opposite / Trade-off:** *(TODO)*
- **Raw Source:** 직접 입력
+## ❌ 안티패턴
+- **Long-lived feature branches**: weeks-old branch 의 merge hell 유발 → trunk-based 로 전환.
+- **Force push to shared branch**: collaborator 의 history rewrite → `--force-with-lease` 만 허용.
+- **Large binaries in Git**: repo size 폭발 → LFS / Artifactory 사용.
+- **Commit messages "fix" "wip" "asdf"**: archaeology 불가 → Conventional Commits 강제 (commitlint).
+- **Branching by environment** (dev/staging/prod branches): merge skew 유발 → trunk + tags + GitOps.

-## 🕓 변경 이력 (Changelog)
+## 🧪 검증 / 중복
+- Verified: Pro Git book (Chacon & Straub, 3rd ed), Git docs, Trunk-Based Development (Hammant).
+- 신뢰도 A.

-| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
-|------|-----------|-----------|--------|
-| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
+## 🕓 Changelog
+| 날짜 | 변경 |
+|---|---|
+| 2026-05-08 | Phase 1 |
+| 2026-05-10 | Manual cleanup — VCS landscape 2026 + Git internals + jj 추가 |