Files
2nd/10_Wiki/Topics/DevOps_and_Security/Version_Control_Systems.md
T
Antigravity Agent f8b21af4be Wiki cleanup: error-doc removal, dedup merge, link normalization
10_Wiki/Topics 대규모 정리:
- 오류 캡처/미완성 stub 문서 227개 제거
- 교차폴더 중복 43클러스터 병합 (63파일 → redirect)
- 링크명 정규화: 깨진 링크 수정·redirect 직결·개념 매핑 ~2,400건
- 카테고리 MOC 6개 신규 생성
- Graph 섹션 미해결 related-keyword 링크 10,058건 제거

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-20 23:52:15 +09:00

4.9 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score verification_status tags raw_sources last_reinforced github_commit tech_stack
wiki-2026-0508-version-control-systems Version Control Systems 10_Wiki/Topics verified self
VCS
Source Control
SCM
none A 0.95 applied
git
vcs
devops
collaboration
2026-05-10 pending
language framework
shell git

Version Control Systems

매 한 줄

"매 source-of-truth + time machine + collaboration substrate". VCS 는 코드 변경 history 를 content-addressable 하게 저장하여 branching/merging/rollback 의 atomic 단위 제공. 매 2026 현재 Git (DVCS) 이 90%+ 시장 — Mercurial, Pijul, Jujutsu (jj) 가 niche 로 존재.

매 핵심

매 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).

매 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.

매 응용

  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).

💻 패턴

Trunk-based development

# 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

Atomic commit + Conventional Commits

git commit -m "feat(auth): add OIDC token refresh

- Refresh 5min before exp
- Exponential backoff on 5xx
- Closes #1423"

Bisect for regression hunt

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

Worktrees for parallel branches

git worktree add ../proj-hotfix hotfix/cve-2026-1234
cd ../proj-hotfix
# Independent working tree, shared .git

Reflog rescue

# Accidentally reset --hard?
git reflog
# 7a3f2b1 HEAD@{2}: commit: WIP feature
git reset --hard HEAD@{2}

Signed commits (supply chain)

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

Jujutsu (jj) workflow — 매 modern alternative

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

LFS for large binaries

git lfs install
git lfs track "*.psd" "*.bin"
git add .gitattributes *.psd
git commit -m "chore: track design assets via LFS"

매 결정 기준

상황 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

기본값: Git + trunk-based development + Conventional Commits + signed commits + GitHub Actions CI.

🔗 Graph

🤖 LLM 활용

언제: commit message 작성, PR description, conflict resolution 설명, git history archaeology. 언제 X: force-push 결정, branch protection policy 설계 — 매 human judgment 필요.

안티패턴

  • 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.

🧪 검증 / 중복

  • Verified: Pro Git book (Chacon & Straub, 3rd ed), Git docs, Trunk-Based Development (Hammant).
  • 신뢰도 A.

🕓 Changelog

날짜 변경
2026-05-08 Phase 1
2026-05-10 Manual cleanup — VCS landscape 2026 + Git internals + jj 추가