GitHub just shipped CLI 1.0, and as someone who has spent most of his career in a terminal, I’m genuinely pleased. The gh command brings GitHub’s core workflows — pull requests, issues, releases, repository management — directly into the command line, without the context-switching overhead of opening a browser.
Yes, there have been third-party tools like hub doing some of this for years. But there’s something meaningful about the official GitHub team building and maintaining this. It signals that terminal-first workflows aren’t a niche preference — they’re a first-class development pattern.
What You Can Actually Do#
The 1.0 release covers the workflows that most developers interact with daily. Here’s what stood out to me:
Pull Requests are the star of the show. You can create, review, check out, and merge PRs without leaving your terminal:
# Create a PR from the current branch
gh pr create --title "Fix caching bug" --body "Resolves #42"
# Check out someone else's PR locally
gh pr checkout 123
# Review and approve
gh pr review 123 --approve
# Merge when ready
gh pr merge 123 --squashIssues get similar treatment. Create them, list them, view them, close them — all from the command line. The gh issue create command even supports labels and assignees directly.
Repository operations round things out. You can create repos, fork them, clone them (with gh repo clone owner/repo instead of remembering the full URL), and view their details.
What I appreciate is the interactive mode. Running gh pr create without flags drops you into a guided flow that asks for title, body, reviewers, and labels. It’s a thoughtful design choice — scriptable when you need automation, interactive when you’re working manually.
Why This Matters More Than You Think#
I can hear the skeptics: “I can do all of this in the browser.” Of course you can. But that’s missing the point.
The value isn’t in any single command — it’s in maintaining flow state. When I’m deep in a debugging session, tracking down a race condition across three services, the last thing I want is to switch to a browser, navigate to the right repo, click through the PR creation form, and then try to remember where I was in my terminal.
With gh, the workflow is:
- Fix the bug in your editor
git add . && git commit -m "Fix race condition in cache invalidation"git pushgh pr create --title "Fix race condition" --reviewer teammate- Continue working
No context switch. No browser tab management. No losing your terminal scroll position. It sounds trivial, but compounded across dozens of PRs per week, it adds up.
There’s also the automation angle. CI scripts, deployment pipelines, and developer tooling scripts can now interact with GitHub’s PR and issue workflows through a stable, official CLI. No more shelling out to curl with raw API calls or maintaining wrapper scripts around the REST API.
The API Integration#
Under the hood, gh wraps GitHub’s GraphQL and REST APIs. This means you also get gh api as a general-purpose tool for hitting any GitHub API endpoint:
# Get repo details as JSON
gh api repos/owner/repo
# List workflow runs
gh api repos/owner/repo/actions/runs --jq '.workflow_runs[].name'The --jq flag for filtering JSON output is a nice touch. For anyone who’s written scripts that pipe curl output through jq to interact with GitHub’s API, this is a cleaner alternative with built-in authentication handling.
What’s Missing#
No tool ships perfect at 1.0, and there are some gaps. GitHub Actions management is limited — you can view workflow runs but can’t trigger them or manage workflow files. Gist support is minimal. Project boards aren’t covered at all.
The extension system is also not yet available, which means you can’t add custom commands. I’d love to see a plugin architecture that lets teams add organization-specific workflows. That would take gh from “useful tool” to “essential infrastructure.”
But these are 1.0 omissions, not design flaws. The foundation is solid, and the team has been responsive to community feedback throughout the beta period.
My Take#
I’ve watched developer tooling evolve substantially over the years, from CVS to SVN to Git, from FTP deployments to CI/CD pipelines, from monolithic IDEs to composable editor setups. The common thread in tools that stick is that they meet developers where they already work, rather than forcing a context switch.
GitHub CLI does exactly that. It doesn’t try to replace the web interface — the browser is still better for code review with complex diffs, for exploring repository insights, and for managing organization settings. What gh does is handle the high-frequency, low-complexity interactions that interrupt your flow when they require a browser.
If you’re a terminal-centric developer (and let’s be honest, most of us are), install it today:
# macOS
brew install gh
# Windows
scoop install gh
# Debian/Ubuntu
sudo apt install ghIt’s open source, cross-platform, and it just works. That’s about the best endorsement I can give any developer tool. The 1.0 label means the GitHub team is committed to stability, and the fact that it’s maintained alongside the platform itself gives me confidence it won’t become abandonware. Welcome to the toolkit, gh.