In our case, we're writing "@changelog [quick summary of the change]" somewhere in our commit message when we think that the commit actually warrants a change l

In our case, we're writing "@changelog [quick summary of the change]" somewhere in our commit message when we think that the commit actually warrants a change log entry. Then as part of the release process, somebody (usually me) uses `git log --grep` to find all the commit messages that developers thought to be change log relevant and writes a document that can be consumed by end users (including screenshots of the features etc). This way end-users can still be informed about changes (most don't care, some notice and complain even when one pixel has moved to a different spot), but we never have issues with merges or rebases (at least not related to change log maintenance :p) Also, in my opinion, keeping a change log for developers is completely unnecessary these days with git and other tools to provide very quick and easy access to the revision history. But for end-users it still makes sense, though it of course has to be on a higher level than individual commits.