Repository navigation
Merge Commits leading to Duplicate Changelog Entries #2476
Description
Hey guys,
I'm having the issue for some time now, that the release-please app is creating duplicate entries for the same change in case my history contains a merge commit of a feature branch. For example:
commit 903930805b446f7f390845adb356c295392260e1
Merge: 8c9b50d f0735d9
Author: xyz
Date: Mon Feb 3 15:29:31 2025 +0100
Merge pull request #178 from BLA/feature/some-feature
feat: change smth
commit f0735d97ed27f93a50d4323af03f8a0b81210c92 (origin/feature/some-feature, feature/some-feature)
Author: xyz
Date: Mon Feb 3 15:24:27 2025 +0100
feat: change smth
leading to
## [1.1.0](https://github.com/BLA/BLUB/compare/v1.0.2...v1.1.0) (2025-02-11)
### Features
* change smth ([9039308](https://github.com/BLA/BLUB/commit/903930805b446f7f390845adb356c295392260e1))
* change smth ([f0735d9](https://github.com/BLA/BLUB/commit/f0735d97ed27f93a50d4323af03f8a0b81210c92))
My unproven assumption is, that #2358 is the cause of that behaviour.
Therefor to my questions:
- Can you confirm my assumption or may there be another cause?
- Is there a mitigation for that problem other than avoiding merge commits?
Thanks in advance!
Activity
chingor13 commentedon Feb 26, 2025
We recommend using squash-merge and do not have current plans to attempt to handle merge commits. https://github.com/googleapis/release-please?tab=readme-ov-file#linear-git-commit-history-use-squash-merge
fix(ci): resolve release-please changelog duplication (#93)
fix(ci): resolve release-please changelog duplication (#93)
fix(ci): resolve release-please changelog duplication (#93)
ci(BSOD-87): deduplicate CHANGELOG entries in auto-release PR (#22)
ringerc commentedon Aug 10, 2026
Squash merges are ... not lovely. They break some valid workflows in more complex repos.
Would the team consider a PR to add merge commit awareness?
Workarounds for this are all undesirable. Either the changelog etc gets duplicate content, or the user has to take special manual action on each merge (error-prone) like adding
BEGIN_COMMIT_OVERRIDEtext. There doesn't seem to be a sensible way to handle this in github automation.I'm thinking of something like a config:
merge-commitswith options:merge-commit-only- only include the merge commit in the changelog. Recommended for new deployments; retains the git metadata from merges (unlike squash merge) but omits the noise from the changelog.omit-merge-commit- only include the individual non-merge commits. Useful when teams produce well-structured, clean merges.tree-under-merge-commit- show simple merge commits as a tree of unique commits by generating a list of all unique commits added by the merge. Should have a commit count limit to handle special cases like a history that has back-merges off a rebased main (resulting in the whole project history appearing as part of the merge commit).docs: document trigger conditions for duplicate changelog entries (#47)
docs: drop the duplicated 1.3.0 changelog entry