> Projects that still insist on maintaining a changelog file in git end up constantly fighting git's conflict resolution, and they make rebase almost completely

> Projects that still insist on maintaining a changelog file in git end up constantly fighting git's conflict resolution, and they make rebase almost completely unusable. It's actually pretty simple - you keep CHANGELOG updates to their own commit, and just aggressively rebase into that commit as you prepare the release. The release owner is the only person who works on the CHANGELOG. We do that at Snowplow and it works really well. Here is the WIP commit for the CHANGELOG for the next Snowplow release: https://github.com/snowplow/snowplow/commit/a862b1e4ab935184c07dfede5fcc333bc70d7a61#diff-d3bb3391c79904494c60ee2ac2f33070 https://github.com/snowplow/snowplow/commit/a862b1e4ab935184... When we finish a release, the CHANGELOG becomes the GitHub release notes: https://github.com/snowplow/snowplow/releases/tag/r60-bee-hummingbird https://github.com/snowplow/snowplow/releases/tag/r60-bee-hu... We are approaching 1 issue : 1 commit : 1 CHANGELOG entry but it's not always possible, and a huge number of open source software users are not technical enough to parse a git log anyway.