I don’t really like the keep-a-changelog idea. Most changelogs get rewritten on release anyway so the main branch’s changelog becomes its own meta-branch of half-baked language that only reaches production state when the release is finalized. Something about that doesn’t sit well with a codebase where everything else has to be production ready all of the time. Where else do you accumulate temporary code/code-like features that need editing and annealing before the code is production ready?

If you have a part of your codebase that’s constantly suffering from merge conflicts then for me that’s a sign that something more fundamental isn’t working. Throwing more code at the problem feels like a hack.

Would you block a change that looked good but had the wrong language for the release notes that was rejected by the person responsible for the release? If one person writes the code and another person releases it, shouldn’t these be two commits anyway?

Perhaps your changelog is for internal use to explain why the codebase changed and when? Why is that not documented in your commit history and instead kept in a mutable part of the codebase?

If you kept each log entry in a file (do people do changelog.d and treat release notes as a compilation step?) then new log entries never conflict and a commit that edits an existing log entry will correctly flag as a conflict with anyone else who made an edit. No tool needed.

I think though, in all honesty, these kinds of ideas are hard to land well. I’m wary of dogmatic advice that — by definition as being a do-this-thing.com — is broadcast-only with a lack of any local context.

(To the author, given that this appears to be a Show HN: although I don’t think this stands up as a general purpose tool, it’s a nice solution and a good example for what a automated merge tool can look like.)