4 ms·

Or you could just filter the commit history and use squash instead of merge.

• slaymaker1907 5y ago
  I still think a changelog may be useful. For example, if you are writing a library, a changelog should include a section for breaking changes. Ideally you should also be providing a migration guide, but a list of breaking changes should be done at a minimum. Git history is also not ideal for giving to users since the history is primarily intended for developers. If you actually want to use git history for this, I actually think non-squash merges are better since you can have the merge commit be very high level and use the other commits for technical details and incremental changes. However, even if you do regular merges, you absolutely still need to keep your history clean via rebasing before sending out a PR. Another tip for keeping your PRs clean without confusing people is to create a separate branch while working on feedback from the PR so you can still manipulate the history as needed while backing up your code to the remote server.
• gitgud 5y ago
  That's better than nothing, but code commits and changelogs have different use cases. Commit logs are for all changes, regardless of size or context. Whereas changelogs are for consumer-facing changes.
  • rp1 5y ago
    That's why you filter it...