GitHub CLI, or gh, is the command-line layer for GitHub work. It lets you authenticate, clone repos, open pull requests, list issues, and automate common GitHub tasks without leaving the terminal.
That sounds simple, but the impact is bigger than a convenience shortcut. Once the CLI becomes part of a normal workflow, it removes a lot of context switching between the browser, the terminal, and local scripts. You can stay in one place while you inspect a repo, create a branch, open a pull request, and check what still needs attention.
The short version
If you only use GitHub in the browser, you are doing more manual work than you need to. If you only use Git, you are missing a lot of the project-management surface area that GitHub already exposes.
gh sits in the middle. It gives you a terminal-native way to do the GitHub tasks that usually force a browser hop.
Why GitHub CLI exists
The GitHub web UI is good for review and discovery, but it is not always the fastest interface for repetitive work. A CLI is better when the task is highly repetitive, scriptable, dependent on local repo state, or part of a development flow you already run from the terminal.
GitHub CLI is not trying to replace the browser entirely. It is trying to move the high-frequency tasks closer to the code.
First step: authenticate once
The first thing most people do is sign in.
gh auth login
That command starts the interactive flow for GitHub.com or GitHub Enterprise. Once you are authenticated, gh can use your account credentials for repo operations, issue actions, pull request commands, and scripting.
You can also use environment variables in automation. The manual documents GITHUB_TOKEN and GH_HOST for scoped setups, which is useful when you are running the CLI in CI or against a specific GitHub instance.
What it replaces in daily work
1 Clone without copying URLs
Use the repo shorthand instead of opening the browser just to copy a remote URL.
2 Create pull requests from context
Turn the current branch into a reviewable PR without leaving the terminal.
3 Inspect issues and reviews fast
List, filter, and inspect GitHub work items directly from your shell.
A practical clone flow
Cloning through gh is one of the simplest quality-of-life improvements.
gh repo clone owner/project-name
cd project-name
That command is useful because it avoids a round-trip through the browser. You do not need to copy the remote URL, paste it into a git clone command, and then remember where the repo came from. GitHub CLI resolves the repository for you.
A practical pull request flow
The pull request workflow is where gh starts to feel like a real developer tool rather than a thin wrapper.
git checkout -b fix/login-error-copy
git add .
git commit -m "Improve login error copy"
gh pr create --fill
--fill is the part that makes the command useful in day-to-day work. It pulls the pull request title and body from your commits, so you can get a review request out quickly and refine it only if needed.
If you need more control, you can still be explicit:
gh pr create --title "Improve login error copy" --body "Clarifies the login failure state and keeps the error message consistent with the form validation copy."
Listing issues without the browser
Issue triage is another good fit for the CLI. You can ask for the issues you care about without loading a web page first.
gh issue list --label bug --state open
If you are doing triage work, that kind of command is often faster than scrolling through the repo UI. It also plays better with scripts, filters, and shell history.
Side-by-side comparison
| Task | GitHub web UI | GitHub CLI |
|---|---|---|
| Authenticate | Browser-based sign-in flow | gh auth login |
| Clone a repo | Open repo, copy remote URL, run Git manually | gh repo clone owner/repo |
| Create a PR | Navigate to the compare page and fill the form | gh pr create --fill |
| Inspect issues | Search and filter in the browser | gh issue list |
| Automate flows | Manual unless you build browser automation | Shell-friendly and scriptable |
The difference is not that one interface is better in every case. The difference is that the CLI is easier to wire into your actual workflow.
Aliases and repeat work
Once you use the same commands often enough, aliases become useful.
gh alias set prs 'pr list --state open'
gh alias set mine 'issue list --assignee @me --state open'
Those aliases do not change the underlying power of GitHub CLI. They just reduce the friction of commands you run every day.
An example review session
Here is what a short review session can look like in practice.
gh auth status
gh repo view owner/project-name
gh issue list --label needs-triage --state open
gh pr list --search "review-requested:@me"
That sequence is useful because it keeps the work local and visible. You can check whether you are authenticated, inspect the repo, review open issues, and find pull requests that need attention without jumping through tabs.
Where GitHub CLI is strongest
What it does not replace
gh is not a substitute for every browser workflow.
It is not the best tool for long-form discussion, visual review of diffs, or exploring a repo for the first time. The browser still wins when you want to read a complicated thread, inspect a design document, or compare a visual artifact.
The useful mental model is simple: use the CLI for action and automation, and use the browser for context and review.
A sensible default
If your team already lives in the terminal, GitHub CLI is worth adopting early. It shortens the path from code change to GitHub action, and it is especially effective when paired with Git aliases, shell scripts, and local automation.
If you only need GitHub once in a while, the web UI is fine. But if you touch repos, issues, and pull requests every day, gh usually pays for itself quickly.
In short, GitHub CLI is not a niche add-on. It is the terminal-native path for the GitHub work that developers repeat most often.