GitHub has released version 1.0 of its CLI, allowing interaction and control of repositories from the command line.
The hosted repository is based on git, which is itself a command-line tool. There is also another project, called hub, which provides a CLI for GitHub. Confusing?
Git alone is not enough for the full GitHub experience, since git is just the repository. Using GitHub Issues, for example, is not a feature of git. Hub wraps git so it supports all git commands, but extends these commands and adds new GitHub-specific commands to manage things such as Issues.
If we have hub, why GitHub CLI? An official document explained: “We wrestled with the decision of whether to continue building onto hub and adopt it as an official GitHub project. In weighing different possibilities, we decided to start fresh without the constraints of 10 years of design decisions that hub has baked in and without the assumption that hub can be safely aliased to git.
“We also wanted to be more opinionated and focused on GitHub workflows, and doing this with hub had the risk of alienating many hub users who love the existing tool and expected it to work in the way they were used to.”
GitHub CLI is official, we are told, whereas hub is “a project whose maintainer happens to be a GitHub employee”. The new tool is not an exact replacement so hub will continue.
GitHub CLI has expanded since the beta in February. One big change is that it now supports GitHub Enterprise Server, the self-hosted version of GitHub. There are also new features, such as the ability to clone, create, and fork repositories, use SSH instead of HTTPS, configure a default editor, and fully manage issues and pull requests, complete with reviewing differences and performing merges. You can also set aliases to make shortcuts for one or more commands.
We installed GitHub CLI on Windows using a downloaded installer – which, as noted in one of the issues, incorrectly installs to Program Files (x86) even though it is a 64-bit application. It is available for macOS, Linux, and Windows. macOS users are directed to Homebrew and MacPorts, Linux users have to add a repository and use apt, while for Windows the official documentation directs developers to the scoop or Chocolatey package managers. Curiously, the docs do not currently suggest Microsoft’s official Windows Package Manager (Winget) even though GitHub CLI 1.0 is already available there. This might be because Winget is still in preview, or evidence that GitHub still runs with a degree of independence from Microsoft, its owners.
The tool itself worked nicely for us, despite a fair number of reported bugs. The advantage for developers is not only the ability to write scripts using GitHub, but also reducing the need to visit the GitHub website – avoiding, for example, unwelcome design decisions. ®
We have no actual insight into how hub’s dev or devs actually feel about this…