GitHub Changelog Generator
- Output example
- Features and advantages of this project
- Am I missed some essential feature?
Changelog generation has never been so easy:
Fully automate changelog generation - This gem generate change log file based on tags, issues and merged pull requests (and split them to separate lists according labels) from GitHub Issue Tracker.
Since now you don't have to fill your
CHANGELOG.md manually: just run script, relax and take a cup of before your next release!
What’s the point of a change log?
To make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project.
Why should I care?
Because software tools are for people. If you don’t care, why are you contributing to open source? Surely, there must be a kernel (ha!) of care somewhere in that lovely little brain of yours.
[sudo] gem install github_changelog_generator
- Look at CHANGELOG.md for this project
ActionSheetPicker-3.0/CHANGELOG.md was generated by command:
github_changelog_generator -u skywinder -p ActionSheetPicker-3.0
In general it looks like this:
- Use milestone to specify in which version bug was fixed #22
- Error when trying to generate log for repo without tags #32
Merged pull requests:
It's really simple:
If your git remote
originrefer to your GitHub repo, then just go to your project folder and run:
or from anywhere:
github_changelog_generator -u github_username -p github_project
As output you will get
CHANGELOG.md file with pretty Markdown-formatted changelog.
github_changelog_generator --help for detailed usage.
Usage: changelog_generator [options] -u, --user [USER] Username of the owner of target GitHub repo -p, --project [PROJECT] Name of project on GitHub -t, --token [TOKEN] To make more than 50 requests per hour your GitHub token required. You can generate it here: https://github.com/settings/tokens/new -f, --date-format [FORMAT] Date format. Default is %d/%m/%y -o, --output [NAME] Output file. Default is CHANGELOG.md --[no-]verbose Run verbosely. Default is true --[no-]issues Include closed issues to changelog. Default is true --[no-]issues-wo-labels Include closed issues without labels to changelog. Default is true --[no-]pr-wo-labels Include pull requests without labels to changelog. Default is true --[no-]pull-requests Include pull-requests to changelog. Default is true --[no-]filter-by-milestone Use milestone to detect when issue was resolved. Default is true --[no-]author Add author of pull-request in the end. Default is true --unreleased-only Generate log from unreleased closed issues only. --[no-]unreleased Add to log unreleased closed issues. Default is true --[no-]compare-link Include compare link between older version and newer version. Default is true --include-labels x,y,z Issues only with that labels will be included to changelog. Default is 'bug,enhancement' --exclude-labels x,y,z Issues with that labels will be always excluded from changelog. Default is 'duplicate,question,invalid,wontfix' --github-site [URL] The Enterprise Github site on which your project is hosted. --github-api [URL] The enterprise endpoint to use for your Github API. -v, --version Print version number -h, --help Displays Help
Since GitHub allow to make only 50 requests without authentication it's recommended to run this script with token (
-t, --token option)
You can easily generate it here.
- Run with key
Or set environment variable
CHANGELOG_GITHUB_TOKENand specify there your token.
i.e. add to your
~/.zshrcor any other place to load ENV variables string :
So, if you got error like this:
! /Library/Ruby/Gems/2.0.0/gems/github_api-0.12.2/lib/github_api/response/raise_error.rb:14:in `on_complete'
It's time to create this token or wait for 1 hour before GitHub reset the counter for your IP.
Features and advantages of this project
- Generate canonical, neat change log file, followed by basic change log guidlines
- Possible to generate Unreleased changes (closed issues that have not released yet)
- GitHub Enterprise support via command line options!
- Flexible format customisation:
- Customize issues, that should be added to changelog
- Custom date format supported
- Ability to manually specify in which version issue was fixed (in case, when closed date is not match) by setting
milestoneof issue the same name as tag of required version
- Automatically exclude specific issues, not-related to change log (any issue, that has label
Distinguish issues according labels.
- Merged pull requests (all
- Bug fixes (by label
- Enhancements (by label
- Issues (closed issues
w/o any labels)
- Merged pull requests (all
You manually can set which labels should be included/excluded.
- Apply a lot of other customisations, to fit changelog for your personal style
github_changelog_generator --helpfor details)
Here is a wikipage list of alternatives, that I found. But no one was satisfy my requirements.
If you know other projects - feel free to edit this Wiki page!
Projects using this library
If you are using
github_changelog_generator for generation change log in your project or know another project that uses it, please add it to this list.
Am I missed some essential feature?
Nothing is impossible!
Open an issue and let's make generator better together!
Bug reports, feature requests, patches, well-wishes are always welcome
- I already use GitHub Releases. Why do I need this?
GitHub Releases is a very good thing. And it's very good practice to maintain it (not so much people using it yet)!
I'm not try to compare quality of auto-generated and manually generated logs.
The Changelog like this sometimes really helps. For example:
When I found a closed bug - it's very useful to understand, in which release it was fixed. In that case you can easily find this issue by # in
- it's not so quite easy to find it in manually filled Releases notes.
- this file can also help you to build your Release note and not miss features in manually-filled list.
In the end:
I think, that GitHub Releases is more for end-users.
CHANGELOG.md could stay in the repo for developers with detailed list of changes.
And it's nothing bad to combine GitHub Releases and
CHANGELOG.md file together in that manner.
- Create an issue to discuss about your idea
- Fork it
- Create your feature branch (
git checkout -b my-new-feature)
- Commit your changes (
git commit -am 'Add some feature')
- Push to the branch (
git push origin my-new-feature)
- Create a new Pull Request
Github Changelog Generator is released under the MIT License.