2nd/10_Wiki/Topic_Programming/DevOps_and_Security/Source-Control.md

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-source-control	Source Control	10_Wiki/Topics	verified	self	version control VCS git workflow	none	A	0.95	applied	git version-control devops workflow collaboration		2026-05-10	pending	language framework shell git-github-jujutsu

Source Control

매 한 줄

"매 commit 의 atomic unit of intent". Source control (VCS) 의 code changes 의 의 history 의 record 의, 매 collaboration / rollback / branching 의 의 enable 의. 2026 의 dominant 의 git, 매 emerging: Jujutsu (jj) 의 ergonomic next-gen, 매 Sapling (Meta).

매 핵심

매 git 의 mental model

• Snapshot, not diffs. 매 commit 의 tree (file content hashes) 의 reference.
• Three trees: working dir, index (stage), HEAD.
• Refs: branches, tags, HEAD 의 commit pointers.
• Object store: blobs, trees, commits, tags — content-addressed (SHA-1/SHA-256).

매 modern workflows

• Trunk-based: short-lived branches (<24h), main 의 always deployable.
• GitHub Flow: feature branch → PR → merge to main.
• GitFlow (legacy): heavy 의 develop/release/hotfix branches — 매 2026 의 거의 not 추천.

매 응용

1. Trunk-based + feature flags (modern PLG SaaS).
2. Stacked PRs (Graphite, Sapling) for big changes.
3. Monorepo (Nx, Turborepo, Bazel).

💻 패턴

Conventional commits + commitlint

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', ['feat','fix','chore','docs','refactor','test','perf','build','ci']],
    'scope-empty': [2, 'never'],
    'subject-max-length': [2, 'always', 72],
  },
};

Pre-push hook (husky)

#!/usr/bin/env bash
. "$(dirname -- "$0")/_/husky.sh"
pnpm test --run && pnpm lint

Squash-merge default + linear history

gh repo edit OWNER/REPO \
  --enable-squash-merge --enable-rebase-merge=false --enable-merge-commit=false \
  --delete-branch-on-merge

Stacked PRs (Graphite)

gt branch create feat-foundation
gt branch create feat-api
gt submit --stack

Bisect 매 regression

git bisect start
git bisect bad HEAD
git bisect good v2.3.0
git bisect run pnpm test:e2e:smoke
git bisect reset

Rerere 의 conflict 의 reuse

git config --global rerere.enabled true

Worktrees 의 parallel branches

git worktree add ../proj-hotfix hotfix/v2.3.1
git worktree remove ../proj-hotfix

Sparse-checkout (monorepo)

git sparse-checkout init --cone
git sparse-checkout set apps/web packages/ui

Signed commits (sigstore gitsign)

gitsign init
git -c commit.gpgsign=true commit -m "feat: thing"
gitsign verify HEAD --certificate-identity=me@org.com \
  --certificate-oidc-issuer=https://accounts.google.com

매 결정 기준

상황	Workflow
SaaS startup, daily deploy	trunk-based + feature flags
OSS library	GitHub Flow + protected main
regulated (releases)	release branches + CHANGELOG
monorepo of apps	trunk-based + Nx affected + sparse

기본값: trunk-based, squash-merge, conventional commits, signed commits (gitsign), CODEOWNERS-protected main.

🔗 Graph

• 부모: DevOps
• 응용: Trunk-Based Development · Code Review · Monorepo
• Adjacent: CODEOWNERS · Conventional Commits · GitOps

🤖 LLM 활용

언제: commit message generation, PR description drafts, conflict resolution suggestions, blame summarization. 언제 X: rebasing 의 LLM-driven 의 unchecked — 매 history 의 corrupt 위험.

❌ 안티패턴

• Long-lived feature branches (>1wk): 매 merge hell.
• Force-push to shared branches: 매 teammates' work 의 destroy.
• Big-bang commits: 매 review impossible, bisect useless.
• No CODEOWNERS: 매 누구나 의 critical path 의 merge.
• Secrets in history: 매 even after rotation, 매 forever exposed.

🧪 검증 / 중복

• Verified (Pro Git book, GitHub flow docs, Trunk-Based Development site, Conventional Commits 1.0).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — git workflow + stacked PR + sigstore patterns