GitHub Goes GUI-less

Git is a handy tool that many of us are using for more than just software development. Having a cloud-based upstream repository is also surprisingly useful, but until now using GitHub — the most common upstream server — meant firing up a web browser, at least for certain tasks. Now GitHub is releasing a beta version of command-line tools made to manipulate your GitHub repos.

The tools are early release so they mostly focus on issues and pull requests. Of course, git itself will do the normal things like clone and checkout — you’ve always been able to do that on the command line. The example given in the announcement blog post lists all issues with a help wanted label:

gh issue list --label "help wanted"

We noticed that asking to view the issue, while done on the command line, will still open a browser. The tools are still a little early, so this is an excellent time to let the developers know what you’d like or otherwise influence the project.

We were a little surprised it wouldn’t just consume git, so that you’d use the same commands for everything and it would just pass pre-formed commands to git. Of course, that would be pretty easy to write as a shell script wrapper if you were interested in such a thing.

You’d be forgiven for only thinking of git as a way to manage source code revisions, but it’s actually capable of all sorts of interesting tricks.

11 thoughts on “GitHub Goes GUI-less

  1. Like fossil, git should integrate issues, PR discussion, forum and all the “good stuff” into the normal local tool to make real peer based development possible. The need for a central hub is a good business model because each git repository clone lacks the most important pieces for the team workflow. So you get a locked in syndrome. Pulling only the access to issues to the commandline without being able to clone issues and all that stuff locally for completely working peer based is not a solution.


    Mail [Linus T.] to finish git by making github/gitlab/… obsolete!

    1. Github/gitlab makes the code available to people outside of core developers circles. Anyone can download a copy of the code (zip of a snapshot of the directory directly from web) *without* some obscured commands, installed specialized software/environments or having to sign up etc. To small developers, it also act as a hosting service or distribution.

      What is “good” for the developers isn’t necessarily good for others.

    2. > completely working peer based

      seems impossible on this Internet.

      When I file a bug to some random person’s project, how do I get everyone to pull it from me into their local repo’s bug tracking system? Where do I push it? At least hosts mailing lists. Yes, that is just another centralized thing, which sometimes is what we need.

    1. Seems like they consider hub unofficial, and gh the ‘official’ CLI. From the readme at

      Comparison with hub
      For many years, hub was the unofficial GitHub CLI tool. gh is a new project for us to explore what an official GitHub CLI tool can look like with a fundamentally different design. While both tools bring GitHub to the terminal, hub behaves as a proxy to git and gh is a standalone tool.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.