Your buddy in managing and maintaining GitHub repositories.
GitBuddy helps you with:
- Generating a changelog
- Converting a tag into a GitHub release with a changelog attached
- Commenting on issues and PRs when a releases contained the related code changes
$ gitbuddy changelog --help
OVERVIEW: Create a changelog for GitHub repositories
USAGE: gitbuddy changelog [--since-tag <since-tag>] [--base-branch <base-branch>] [--sections] [--verbose]
OPTIONS:
-s, --since-tag <since-tag>
The tag to use as a base. Defaults to the latest tag.
-b, --base-branch <base-branch>
The base branch to compare with. Defaults to master.
--sections Whether the changelog should be split into sections. Defaults to false.
--verbose Show extra logging for debugging purposes
-h, --help Show help information.
This command generates a changelog based on merged PRs and fixed issues. Once a PR contains a reference like "Fixed #30"
, the title of issue 30 will be included in the changelog. Otherwise, the Pull Request title will be used.
Pull requests that are merged into the baseBranch
will be used as input for the changelog. Only pull requests that are merged after the creation date of the sinceTag
are taken as input.
This is an example taken from Mocker
- Switch over to Danger-Swift & Bitrise (#34) via @AvdLee
- Fix important mismatch for getting the right mock (#31) via @AvdLee
If you'd like a changelog to link to issues closed before a release was tagged, pass the --sections
argument, then it's going to look like this:
Closed issues:
- Can SPM support be merged branch add-spm-support be merged to master? (#33)
- migrate 2.0.0 changes to spm compatible branch
feature/add-spm-support
? (#32)
Merged pull requests:
- Switch over to Danger-Swift & Bitrise (#34) via @AvdLee
- Fix important mismatch for getting the right mock (#31) via @AvdLee
$ gitbuddy release --help
OVERVIEW: Create a new release including a changelog and publish comments on related issues.
USAGE: gitbuddy release [--changelog-path <changelog-path>] [--skip-comments] [--use-pre-release] [--target-commitish <target-commitish>] [--tag-name <tag-name>] [--release-title <release-title>] [--last-release-tag <last-release-tag>] [--base-branch <base-branch>] [--sections] [--verbose]
OPTIONS:
-c, --changelog-path <changelog-path>
The path to the Changelog to update it with the latest changes.
-s, --skip-comments Disable commenting on issues and PRs about the new release.
-p, --use-pre-release Create the release as a pre-release.
-t, --target-commitish <target-commitish>
Specifies the commitish value that determines where the Git tag is created
from. Can be any branch or commit SHA. Unused if the Git tag already exists.
Default: the repository's default branch (usually master).
-n, --tag-name <tag-name>
The name of the tag. Default: takes the last created tag to publish as a GitHub
release.
-r, --release-title <release-title>
The title of the release. Default: uses the tag name.
-l, --last-release-tag <last-release-tag>
The last release tag to use as a base for the changelog creation. Default:
previous tag.
-b, --base-branch <base-branch>
The base branch to compare with for generating the changelog. Defaults to
master.
--sections Whether the changelog should be split into sections. Defaults to false.
--verbose Show extra logging for debugging purposes
-h, --help Show help information.
The release
command can be used to transform the latest tag into a GitHub release including the changelog as a body.
The changelog is generated from all the changes between the latest and previous tag.
The changelog is appended to the beginning of the changelog file if a changelogPath
is passed. It's most commonly set to Changelog.md
.
It's best to use this on a release branch so you can commit the changes and open a PR.
A great feature of this release command is the automation of posting comments to issues and PRs that are released with this release.
A comment posted on a pull request
Installation using Mint
You can install GitBuddy using Mint as follows:
$ mint install WeTransfer/GitBuddy
Setup a personal access token with the scope set to repo
only. Add this token as an environment variable GITBUDDY_ACCESS_TOKEN
by combining your GitHub username with the token:
export GITBUDDY_ACCESS_TOKEN="<username>:<access_token>"
The token is used with the GitHub API and uses Basic HTTP authentication.
After that you can directly use it by executing it from within the repo you would like to work with:
$ gitbuddy --help
OVERVIEW: Manage your GitHub repositories with ease
USAGE: gitbuddy [--version] <subcommand>
OPTIONS:
--version Prints the current GitBuddy version
-h, --help Show help information.
SUBCOMMANDS:
changelog Create a changelog for GitHub repositories
release Create a new release including a changelog and publish comments on related issues.
cd
into the repository- run
swift package generate-xcodeproj
(Generates an Xcode project for development) - Run the following command from the project you're using it for:
swift run --package-path ../GitBuddy/ GitBuddy --help