GitHub just released their version 1.0 of their CLI, allowing interaction and repository control from the command line. The hosted repository has it’s foundation on Git, which is a command-line tool in itself. In addition to this, a project called hub gives users a CLI for GitHub.
You see, Git by itself is not sufficient to give you the full experience GitHub delivers. Git is just the repository in this scenario. So, when you use something like GitHub Issues, for instance, you are not using a Git feature.
A tough decision
Hub encompasses Git, which is why it supports all git commands. It also extends the commands and provides additional GitHub-specific commands that manage other features like GitHub Issues. So, if we have hub, why GitHub CLI?
According to an official document explaining this, the people behind the idea had a hard time deciding whether to continue building onto hub and take this new version as an official GitHub project.
After weighing the possibilities, they started afresh with constraints borne of over a decade of design.
Hub will continue
They also wanted to be more opinionated and focused on GitHub workflows. Doing this with hub would risk alienating many hub users who love the existing version of the tool and expect it to work a certain specific way that they are used to.
GitHub CLI is official, and hub is seen as a project whose maintainer happens to be a GitHub employee. This new tool is not exactly a replacement, meaning that hub will continue.
GitHub CLI’s beta was released in February and has expanded since then. One of the significant changes is that it now supports GitHub Enterprise Server (a self-hosted version of GitHub)