Bug Report

Description

First of all, thank you for a great tool, you did an amazing work!

I have a usual flow with GitHub action that is running after the merge (exactly the one that is described in documentation). And it looks like in case of merge commits it can produce empty release and changelog, but still bump a version.
I have main branchandfeature` branch. The history looks like this

*   v1.2.0 release (main)
*   Merge `feature into `main`
|  \
|   *   Merge 'main' into 'feature' to get latest changes (feature)
| / |
|   |  
*   |    v1.1.0 release (main)
*   |    Some commit in main
|   |
|   *   feat: My new feature (feature)
|  /  
|  

Expected behavior

v1.2.0 release is created, release contains feat: My new feature commit in changelog and release.

Actual behavior

v1.2.0 release is created, but CHANGELOG.md and GitHub release are empty, they don't contain feat: My new feature, just blank

## v1.2.0 (2025-05-23)

Environment

• Operating System (w/ version): Ubuntu 25.04
• Python version: 3.10
• Pip version: 25.1.1
• Semantic-release version: 9.21.1
• Build tool (w/ version): None

Configuration

[tool.semantic_release]
version_toml = ["pyproject.toml:project.version"]

[tool.semantic_release.changelog]
mode = "update"

Additional context

As I understand, the problem is not in python-semantic-release directly; the problem is the git log output format. Even with topo_order=True here, it still puts my feat: My new feature commit before the v1.1.0 release commit in the history. It looks like after the Merge 'main' into 'feature' to add the latest changes commit, the git log command decided to show commits from main before showing commits from feature.

Why the PR title mentions inconsistency is because in the version resolving logic, the _traverse_graph_for_commits() function returns the correct list of new commits since the last release.
As a result, the version is calculated correctly, but there are no new commits in the release history, so the changelog and release notes are empty.

An obvious idea would be to use _traverse_graph_for_commits()-like logic in ReleaseHistory.from_git_history() to get unreleased commits. But I assume it's not that simple, or it would have been implemented this way already.
I'm happy to provide more info or prepare a PR if you have an idea of how to deal with this behavior.