Files
2nd/10_Wiki/Topics/DevOps_and_Security/Commit_History.md
T
2026-05-10 22:08:15 +09:00

4.0 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-commit-history Commit History 10_Wiki/Topics verified self
Git Log
Commit Log
Git History
none A 0.9 applied
git
vcs
history
2026-05-10 applied
language framework
Bash Git

Commit History

매 한 줄

"매 commit 은 미래의 자기 자신을 위한 편지다.". Commit history 는 매 codebase 의 시간축 — bisect, blame, revert, audit 의 매 기반. 2026 의 표준은 Conventional Commits + signed commits (Sigstore gitsign / SSH key) + linear history (rebase or squash-merge).

매 핵심

매 좋은 history 의 특징

  • Atomic: 매 한 commit = 한 logical change.
  • Descriptive subject: 50자, imperative — "Fix login race".
  • Body explains why: 매 what 은 diff 가 보여줌 — why 가 commit 의 가치.
  • Linkable: issue/PR ref.
  • Signed: GPG / SSH / gitsign — supply-chain integrity.
  • Linear or trunked: bisect 친화적.

매 Conventional Commits

<type>(<scope>): <subject>

<body>

<footer>
  • type: feat, fix, refactor, perf, test, docs, chore, build, ci.
  • 매 BREAKING CHANGE: footer.

매 응용

  1. Bisect — 매 regression commit 이분 탐색.
  2. Blame — 매 line author/intent 추적.
  3. Cherry-pick — hotfix backport.
  4. Revert — production rollback.
  5. Changelog — automated (release-please, semantic-release).
  6. Audit — compliance, post-mortem.

💻 패턴

git bisect 자동화

git bisect start
git bisect bad HEAD
git bisect good v1.2.0
git bisect run npm test       # 매 each step automated
git bisect reset

Signed commit (gitsign / Sigstore)

# 매 keyless OIDC sign
git config --global gpg.x509.program gitsign
git config --global gpg.format x509
git config --global commit.gpgsign true
git commit -m "feat: signed via gitsign"
git verify-commit HEAD

Conventional Commits + commitlint

// commitlint.config.js
export default {
  extends: ['@commitlint/config-conventional'],
  rules: { 'subject-max-length': [2, 'always', 72] },
};

Interactive rebase cleanup (before push)

git rebase -i origin/main   # 매 squash, reword, reorder

git log advanced query

# 매 작가별 last week
git log --since='1 week ago' --pretty=format:'%h %an %s'
# 매 specific file 의 changes (move 추적)
git log --follow -p src/auth.ts
# 매 grep in patches
git log -G 'eval\(' --oneline

release-please automation

- uses: googleapis/release-please-action@v4
  with: { release-type: node }
# 매 Conventional Commits → CHANGELOG.md + version bump PR

매 결정 기준

상황 Approach
Feature branch rebase + squash-merge
Long-running branch merge commit (주의)
Hotfix cherry-pick to release
Breaking change BREAKING CHANGE footer + major bump
Compliance signed commits + protected branch

기본값: 매 Conventional Commits + signed + squash-merge.

🔗 Graph

🤖 LLM 활용

언제: commit message 생성, PR description, changelog draft, post-mortem timeline 정리. 언제 X: 매 actual git operations — automation 이 deterministic.

안티패턴

  • "WIP" commit: 매 squash 전 cleanup.
  • 거대 commit: 매 review 불가 — split.
  • Force-push to shared branch: 매 history rewrite, others lose work.
  • Unsigned in regulated: 매 SOC2/SLSA 위반.
  • git add . blindly: 매 secret 유출 위험.

🧪 검증 / 중복

  • Verified: Conventional Commits 1.0; Sigstore gitsign docs; Git docs.
  • 신뢰도 A.

🕓 Changelog

날짜 변경
2026-05-08 Phase 1
2026-05-10 Manual cleanup — Conventional Commits + signing + bisect