Git History Review

The Problem

Git history is a project’s institutional memory — but most teams treat it as a dumping ground. Commits like “fix stuff,” “WIP,” and “final final v3” tell future developers nothing about what changed or why. Feature branches live for months, accumulating dozens of merge commits that obscure the actual work. When a production bug appears and someone runs git bisect, they find it impossible to isolate the breaking change because the history is a noise-filled stream of meaningless snapshots.

The Prompt

Review the following git history. Act as a staff engineer evaluating the team's version control practices for clarity and traceability.

GIT LOG:
[paste output of git log --oneline --graph -30 or similar]

RECENT DIFFS (optional):
[paste key commit diffs that concern you]

Evaluate across these dimensions:

1. **Commit Messages**
   - Do messages explain WHAT changed and WHY (not just "fix bug")?
   - Is there a consistent format (conventional commits, prefix tags)?
   - Are messages concise in subject (<72 chars), detailed in body?
   - Do messages reference issue/ticket numbers?

2. **Commit Granularity**
   - Is each commit a single logical change (not 5 unrelated fixes)?
   - Are there empty commits, WIP commits, or "oops" fix-up commits?
   - Would `git bisect` be effective (each commit builds and tests pass)?

3. **Branch Strategy**
   - Are feature branches short-lived (merged within days, not weeks)?
   - Is the branching model clear (trunk-based, gitflow, GitHub flow)?
   - Are branch names descriptive (feat/, fix/, refactor/)?

4. **Merge Hygiene**
   - Are merge commits clean or do they show unnecessary conflicts?
   - Is the team using rebase or squash for clean history?
   - Are there merge commits that accidentally revert previous changes?

5. **Sensitive Data**
   - Were any secrets, credentials, or .env files ever committed?
   - Were large binary files committed that should be in LFS or .gitignore?
   - Is the .gitignore comprehensive for the project type?

6. **Traceability**
   - Can you trace a code change back to a requirement or bug report?
   - Are PRs linked to issues?
   - Is the deploy history visible from tags or release branches?

For each issue, provide:
- **Commit(s)**: SHA or message
- **Problem**: Why this hurts the team's ability to maintain the codebase
- **Severity**: audit-risk / confusion / style
- **Fix**: Corrected practice or retroactive cleanup

Example Output

## Git History Review: 4 issues found

### Confusion: Meaningless Commit Messages
Commits: "fix" (x7), "update" (x4), "WIP" (x3), "stuff" (x2)
Problem: git blame and bisect are useless when messages carry no information.
Fix: Adopt conventional commits:
  feat(auth): add password reset flow (#234)
  fix(cart): prevent double charge on retry (#567)
  refactor(api): extract validation middleware

### Audit Risk: Secret Committed and Removed
Commit: abc123 "add config" — .env with DATABASE_URL committed
Commit: def456 "remove env" — .env deleted in next commit
Problem: Secret still exists in git history. Anyone with repo access can retrieve it.
Fix: Rotate the DATABASE_URL credential immediately. Use git-filter-repo to purge from history.

### Confusion: Long-Lived Feature Branch
Branch: feature/redesign — 47 commits over 3 months, 12 merge commits
Problem: Code review is impossible on a 2,000-line diff. Merge conflicts compounded.
Fix: Break large features into incremental PRs (behind feature flags if needed).

When to Use

Run this when onboarding to a project, during team process reviews, or when git bisect fails to help find a regression. Valuable as a periodic audit (quarterly) to catch bad habits before they become team culture. Use it to establish commit conventions at project kickoff.

Pro Tips

• Include the git graph — use git log --oneline --graph --all -30 to show branch structure, not just linear history.
• Check for secrets retroactively — ask “Scan this git log for any commits that might have included secrets, API keys, or credential files.”
• Establish conventions early — follow up with “Generate a CONTRIBUTING.md section with commit message guidelines, branch naming rules, and PR template.”