---
id: wiki-2026-0508-version-control-systems
title: Version Control Systems
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [VCS, Source Control, SCM]
duplicate_of: none
source_trust_level: A
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

## 매 한 줄
> **"매 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
```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
```

### Atomic commit + Conventional Commits
```bash
git commit -m "feat(auth): add OIDC token refresh

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

### 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
```

### Worktrees for parallel branches
```bash
git worktree add ../proj-hotfix hotfix/cve-2026-1234
cd ../proj-hotfix
# Independent working tree, shared .git
```

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

### 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
```

### 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
```

### 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"
```

## 매 결정 기준
| 상황 | 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
- 부모: [[Software-Engineering]] · [[Collaboration-Tools]]
- 변형: [[Git]] · [[Mercurial]] · [[Perforce]] · [[Jujutsu]] · [[Pijul]]
- 응용: [[GitOps]] · [[CI-CD]] · [[Code-Review]] · [[DVC-ML-Versioning]]
- Adjacent: [[Monorepo-Tools]] · [[Branch-Strategies]] · [[Conventional-Commits]]

## 🤖 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 추가 |
