agentsclimarketplace

Git history hygiene

Skill Amey-Thakur/AI-SKILLS/skills/git-collaboration/git-history-hygiene

Plug-and-play skills and prompts for every AI coding agent

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill git-history-hygiene

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Keep git history atomic, bisectable, and readable with curated commits and disciplined force-push. Use when commits are messy, history is hard to navigate, or bisect and blame mislead.

SKILL.md

3.4 KB, 793 tokens by cl100k_base, as published. Nobody here has run it

Git history hygiene

Git history is documentation that writes itself if you let it: a readable log lets future-you bisect a bug to one small commit and blame a line to its reason. Messy history (a hundred "wip", "fix", "actually fix" commits) throws that away.

Method

  1. Make each commit one logical change that builds. A commit does one thing (a feature increment, a fix, a refactor: never a fix plus an unrelated cleanup) and leaves the code compiling and passing tests: so every commit is a valid bisect point (see below) and can be reverted cleanly. "One logical change" is the atomic-commit rule that makes everything else possible.
  2. Write commit messages that explain why. Subject line in the imperative, under ~50 chars, summarizing the change; body explaining the why and context the diff cannot show (see commit-messages). The diff shows what changed; the message is where the reasoning lives, and it is the highest-leverage documentation you will ever write because it is attached forever to the exact change.
  3. Curate before sharing, not after. During development, commit freely (wip, checkpoints); before opening the PR or merging, interactive-rebase into a clean sequence (squash fixups, reorder, reword: see merge-vs-rebase). The reviewer and history see intent; your messy process stays private. Squash-and-merge automates this at the PR level if the team prefers (see merge-vs-rebase).
  4. Keep history bisectable. git bisect finds the commit that introduced a bug in log(n) steps: it only works if every commit builds and the history is granular enough to localize. Atomic, building commits (step 1) are what make bisect the debugging superpower it is (see binary-search-debugging); a history of giant or broken commits defeats it.
  5. Force-push only your own branches, with lease. --force-with-lease (never bare --force) on your private branch is fine (curating before review); force-pushing shared branches rewrites others' history (the cardinal sin: see merge-vs-rebase). After a shared commit lands, changes go forward (revert), never by rewriting.
  6. Undo forward on shared history. git revert creates a new commit undoing a bad one, preserving the record that it happened and was reversed: honest and safe on shared branches; the reflog (git reflog) recovers local mistakes for ~90 days, so local experimentation carries no real risk.

Boundaries

  • History hygiene serves navigation and debugging, not vanity; a team that squash-merges every PR has clean history without per-commit curation, a valid trade (see merge-vs-rebase). Match effort to how much the team actually uses granular history.
  • Do not over-curate to the point of hiding real development reality where it matters (a genuinely complex change's steps can be worth preserving); the goal is readable-and-useful, not artificially pristine.
  • Generated files, secrets, and large binaries do not belong in history at all (they bloat the repo forever and secrets stay recoverable: see secrets-management, git-hooks-automation for prevention); .gitignore and hooks prevent, history-rewriting to remove them after is painful.

Gives 0 of the 12 instructions most pr commit review skills give in 793 tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-06

  • use conventional commits formatin 123 of 888, across 110 files
  • keep subject line under 72 charactersin 60 of 888, across 46 files
  • delete branches after mergein 50 of 888, across 37 files
  • use imperative mood in subject linein 50 of 888, across 41 files
  • use imperative mood in commit messagesin 45 of 888
  • generate a conventional commit messagein 42 of 888
  • make atomic commitsin 37 of 888, across 25 files
  • run tests before committingin 36 of 888, across 24 files
  • run project test suite to verify clean baselinein 35 of 888, across 7 files
  • run detected project setup commandsin 34 of 888, across 6 files
  • wrap commit body at 72 charactersin 32 of 888, across 25 files
  • split unrelated changes into separate commitsin 32 of 888, across 27 files

Said here and by no other author read

  • curate history before sharing
  • keep history bisectable
  • undo shared history forward with revert
  • exclude generated files secrets and binaries from history

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.