**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 :octocat: GitHub Issue Tracker.
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.
> - PrettyPrint class is included using lowercase 'pp' [\#43](https://github.com/skywinder/Github-Changelog-Generator/pull/43) ([schwing](https://github.com/schwing))
>
> - support enterprise github via command line options [\#42](https://github.com/skywinder/Github-Changelog-Generator/pull/42) ([glenlovett](https://github.com/glenlovett))
-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.
- Ability to manually specify in which version issue was fixed (in case, when closed date is not match) by setting `milestone` of issue the same name as tag of required version :pushpin:
- Automatically **exclude specific issues**, not-related to change log (any issue, that has label `question``duplicate``invalid``wontfix`by default) :scissors:
Here is a [wikipage list of alternatives](https://github.com/skywinder/Github-Changelog-Generator/wiki/Alternatives), that I found. But no one was satisfy my requirements.
*If you know other projects - feel free to edit this Wiki page!*
*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] (https://github.com/skywinder/Github-Changelog-Generator/wiki/Projects-using-Github-Changelog-Generator) list.*
- ***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)! :congratulations:
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 `CHANGELOG.md`.
- 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.
But `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.
