Purpose

Provides a repo fixture to reproduce the problem described in#1252 (based onthis comment)

Rationale

Added a new repo following the examples in other fixtures.
Had to made one more addition:simulate_change_commits_n_rtn_changelog_entry() fixture always worked with thefile_in_repo. For this specific flow it caused merge conflicts, because commit in the feature branch was made before default branch was merged into a feature branch. Made this parameter configurable.

How did you test?

I ran the test and it failed with the expected error (empty## v0.3.0 (2025-05-31) changelog entry)

>           assert expected_md_changelog_content == actual_md_changelog_contentE           assert == failed. [pytest-clarity diff shown]E             E             LHS vs RHS shown belowE             E               # CHANGELOGE               E               <!-- version list -->E               E               ## v0.3.0 (2025-05-31)E             + E             + ### FeaturesE             + E             + - Add new feature in the feature branchE             +   E             ([`0000000`](https://example.com/example_owner/example_repo/commit/0000000000000E             000000000000000000000000000))E               E               E               ## v0.2.0 (2025-05-31)E               E               ### FeaturesE               E               - Add another featureE                 ([`0000000`](https://example.com/example_owner/example_repo/commit/000000000E             0000000000000000000000000000000))E               E               E               ## v0.1.0 (2025-05-31)E               E               - Initial ReleaseE

How to Verify

1. Comment (or remove@pytest.mark.xfail decorator on thetests/e2e/cmd_version/bump_version/trunk_based_dev/test_repo_w_feature_branch_and_release_in_default.py test.
2. runpytest -vv --comprehensive tests/e2e/cmd_version/bump_version/trunk_based_dev/test_repo_w_feature_branch_and_release_in_default.py

PR Completion Checklist

• Reviewed & followed theContributor Guidelines

• Changes Implemented & Validation pipeline succeeds

• Commits follow theConventional Commits standard
  and are separated into the proper commit type and scope (recommended order: test, build, feat/fix, docs)

• Appropriate Unit tests added/updated

• Appropriate End-to-End tests added/updated

• Appropriate Documentation added/updated and syntax validated for sphinx build (see Contributor Guidelines)