fix(algorithm): ignore unreleased commit/revert pairs - #1506

Purpose

A breaking change followed by its revert can still trigger a major release even when neither commit has been released. Ignore an unambiguous ordinary commit/revert pair when determining the automatic next version. References #402.

Rationale

Match standard Git Revert/Reapply or conventional revert subjects with a complete commit reference inside the current release window. Process the reference graph independently of history traversal order so a revert of a revert restores the original impact. Preserve a connected group when multiple reverts point to the same target, avoiding order-dependent results.

Forced bumps, already-released targets, and historical changelog entries retain their existing behavior. Git merge reverts (git revert -m) remain outside this pairing because their impact can include commits from the merged parent history. The documentation describes these boundaries.

How did you test?

• Fourteen real-Git CLI regressions/controls: the exact base fails nine cancellation-dependent cases and passes five controls; the fix passes all fourteen.
• Twenty-five focused unit cases include revert chains, CRLF/byte messages, unrelated SHA mentions, cycles, and 720 permutations of an ambiguous history.
• Full unit selection: 4319 passed, 15 skipped. Full default e2e selection: 279 passed, 708 comprehensive cases skipped.
• Version-command comprehensive selection: 770 passed, 3 skipped, 6 xfailed; four existing missing-tag failures also reproduce with the exact base.
• Full Ruff lint/format checks pass. Both changed production files pass Mypy; the full-tree check reports the same four existing import-redefinition errors on base and candidate.
• Documentation and source/wheel builds pass. The three existing clean documentation warnings reproduce on the exact base.
• An independent agent verified seven real CLI subprocess journeys, exact-base behavior, and ambiguity handling against the final file hashes.

Implemented with OpenAI Codex and independently reviewed by a separate Codex agent; no human review is claimed.

How to Verify

Run the new tests in tests/unit/semantic_release/version/test_reverts.py and tests/e2e/cmd_version/test_version_reverts.py. In a tagged repository, create a breaking change, run git revert on it, and run semantic-release version --print: the existing version should remain. Revert the revert and the breaking version impact should return.

PR Completion Checklist

• Reviewed & followed the Contributor Guidelines
• Changes implemented & validation pipeline succeeds (local results above; upstream CI pending)
• Commits follow Conventional Commits and are separated by type
• Appropriate Unit tests added
• Appropriate End-to-End tests added
• Appropriate Documentation added and Sphinx build validated