Getting Started with GitHub CLI (gh): GitHub From Your Terminal

If you live in a terminal all day, the GitHub web UI can feel… slow.

Click into a repo.
Wait.
Click into Pull Requests.
Wait.
Open an issue.
Wait.

GitHub CLI—gh—short-circuits all of that. It brings GitHub concepts like pull requests, issues, releases, and workflows straight into the shell you already have open next to your code.

This article is a “getting started” tour:

• What gh is and how it fits with git
• How to install it
• How to authenticate it with your GitHub account
• A handful of basic commands you can start using immediately

We’ll save a detailed deep dive into gh pr for a follow-up article.

What is GitHub CLI (and how is it different from git)?

It’s easy to confuse Git, GitHub, and GitHub CLI, because they’re usually mentioned in the same breath. Git is the underlying version control system you use to track changes in your code: you create commits, branch and merge, and inspect history with commands like git commit, git checkout, and git log. GitHub is the hosted service that sits on top of Git repositories and adds collaboration features such as pull requests, issues, releases, workflows, and discussions.

GitHub CLI—gh—is a bridge between those two worlds. It does not replace git; instead, it lives alongside it in your terminal. You still reach for git when you’re working with your local repository and commit history. You reach for gh when you want to interact with GitHub itself: creating and reviewing pull requests, listing and updating issues, kicking off or inspecting workflow runs, managing releases, and generally doing the things you’d normally do in the GitHub web UI.

One way to think about it is that git talks to your repository, while gh talks to your GitHub account. Both are command‑line tools, and you’ll often use them together in the same shell session, but each focuses on a different layer of your development workflow.

Installing gh

Here’s the practical, “just give me the command” version for common environments:

macOS (Homebrew)

After installation, you should be able to run:

…and see the installed version printed.

Debian/Ubuntu (APT)

Fedora / RHEL-ish (DNF)

Windows (Winget)

From an elevated PowerShell or Command Prompt:

Again, check:

If you’re working in a more exotic environment (containers, GitHub Enterprise, etc.), it’s worth skimming the official installation page for the latest options and any caveats.

Authenticating gh with GitHub

Once gh is installed, the next step is to log it into your GitHub account.

The easiest way is the interactive login:

gh will ask a series of questions:

1. Which GitHub host?
   • For most people: github.com
   • For GitHub Enterprise: your custom hostname (e.g. github.mycompany.internal)
2. What protocol should it use for Git operations?
   • https or ssh (if you already use SSH keys with GitHub, pick ssh.)
3. How do you want to authenticate?
   • Usually a browser-based OAuth flow (--web) where you paste or confirm a one-time code and approve the CLI.

If you prefer to script this or you’re on a headless server, you can also authenticate with a token:

gh respects environment variables like GH_TOKEN and GITHUB_TOKEN, which let you skip interactive login completely—handy in CI pipelines or other non-interactive contexts.

To double-check your status:

That will tell you which host you’re authenticated to and with what scopes.

Your First gh Commands

With gh authenticated, you can start poking around your GitHub world from the terminal.

Cloning repositories

You can clone by OWNER/REPO instead of typing the full URL:

Behind the scenes this uses the Git protocol you selected (ssh or https) during gh auth login.

You can also view repository details:

Run that inside a cloned repo to see its GitHub metadata (description, default branch, visibility, etc.).

Browsing a repo in your browser

Sometimes you want to jump into the GitHub UI from wherever your shell happens to be:

• Run this inside a repo to open that repo’s GitHub page.
• Add a path to open a specific file:
  
  gh browse path/to/file.go

  1 2	gh browse path/to/file.go

Great for “I know what I want, just don’t make me click through twelve pages to get there.”

Listing issues

A simple way to see what’s going on in a project:

You can then drill into an issue:

That will show you the title, body, status, and some metadata right in your terminal.

Creating a new issue is just as straightforward:

gh will drop you into your editor (or prompt inline) for the title and body.

A sneak peek at pull requests

We’ll dedicate a full article to gh pr, but you can already start using it for quick visibility:

Think of these as the “PR dashboard” you can check without leaving your terminal.

Help, configuration, and aliases

A few quality-of-life improvements make gh feel like part of your normal toolkit instead of a bolt-on.

Discovering commands with gh help

The CLI has a lot of surface area—core commands like gh repo, gh issue, gh pr, and then more specialized ones like gh release, gh project, gh run, gh search, etc.

To see what’s available:

To drill into a specific command:

Help is built in; you don’t have to keep a browser tab open to the docs.

Setting your editor and other defaults

You can tune some defaults via gh config:

gh also respects env vars like GH_EDITOR, EDITOR, GH_BROWSER, and friends for picking tools and behavior.

Creating shortcuts with aliases

If you find yourself typing the same gh commands repeatedly, you can create aliases:

Aliases are just shortcuts, but they help you shape gh around your own workflow instead of memorizing long command lines.

Where to go next

At this point you should have:

• gh installed on your machine
• Your GitHub account authenticated
• A feel for basic commands like gh repo clone, gh browse, gh issue list, and a preview of gh pr

From here, there are a few natural next steps:

• Make gh part of your everyday habits: use it for morning triage of issues/PRs.
• Explore gh help for commands that match the parts of GitHub you touch the most (releases, workflows, projects).
• Start thinking about “terminal-only” workflows where you don’t need to open the browser at all.

In a follow-up article, we’ll zoom in on gh pr and walk through a full pull-request workflow—creating, reviewing, checking CI status, and merging—without ever leaving your terminal.