GitBuddy

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

Generating a changelog

$ 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.

A Changelog example

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

Generating a release

$ 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.

Updating the changelog file

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.

Post comments

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 an issue

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.

Development

cd into the repository
open the Package.swift file
Run the following command from the project you're using it for:

swift run --package-path ../GitBuddy/ GitBuddy --help

WeTransfer/GitBuddy

WeTransfer

Reviews

Repository Details