Browserless Workflows

Every time you Alt-Tab from your terminal to a browser to check if a CI pipeline passed, you're bleeding focus. It’s a small tax, but over an eight-hour day, these micro-interruptions aggregate into a fragmented mess that keeps you from actually finishing your work.

I used to think the GitHub web UI was the "canonical" way to manage a project. I'd commit my code, then immediately mouse over to Chrome to open a Pull Request. It felt like a natural break, but it usually ended with me accidentally checking Twitter or getting lost in a sea of open tabs. Then I started leaning heavily on the GitHub CLI (`gh`), and my workflow stopped feeling like a relay race and started feeling like a straight line.

The "One Command" PR

The most common reason people leave the terminal is to open a Pull Request. You push your branch, then you go to the repo page to click the big green button.

Instead, try this:

gh pr create --fill --web

The --fill flag is the hero here—it automatically pulls your commit titles and bodies to populate the PR description. If you add --web, it opens the browser just for that final review. But if you want to stay strictly in the shell, just run:

gh pr create --title "feat: add oauth logic" --body "Fixes #124"

I’ve found that writing PR descriptions in my local $EDITOR (usually Vim or VS Code) results in much better documentation than typing into a cramped textarea in a browser.

Reviewing Code Without the GUI

Reviewing code in a browser is fine for small changes, but if you need to actually *run* the code or check it against a complex local environment, the web UI is a bottleneck.

When a teammate asks for a review, I don't go looking for the branch name. I just list the open PRs:

gh pr list

Once I find the one I need (let's say it's #42), I check it out locally:

gh pr checkout 42

This command handles the heavy lifting of fetching the remote branch and switching to it. I can run tests, grep the codebase, and see the changes in my own IDE. When I’m done, I can even submit my review from the terminal:

gh pr review --approve -b "Looks solid, tests pass locally."

Watching the "Spinning Circles"

Waiting for CI/CD is the ultimate productivity killer. You push code, wait for GitHub Actions to trigger, and then sit there hitting refresh.

You can bypass this by "watching" the run directly from your shell:

gh run watch

This gives you a live-updating view of your active workflows. If a job fails, you don't even have to scroll through a web console. You can view the logs for the failed run immediately:

gh run view --log-failed

It’s much faster than digging through the "Actions" tab and clicking through three layers of nested menus just to see which linting rule you broke.

Managing Releases

If you’re responsible for tagging versions, the CLI makes it trivial. Instead of navigating to the "Releases" page and manually typing out a changelog, let GitHub do the work:

gh release create v1.2.0 --generate-notes

This creates a tag, a release, and automatically compiles a list of all the PRs that went into this version. If you have binaries or assets to upload, just append the file paths to the end of the command.

Making it Yours (Aliases)

The gh tool is great, but some commands are wordy. I recommend setting up aliases for the things you do ten times a day. You can do this via the CLI itself:

# Shortcut to see the status of your current branch's PR
gh alias set status 'pr status'

# Shortcut to see what's failing in CI right now
gh alias set checks 'run list --limit 5'

Now, typing gh status gives me a snapshot of my PR’s review status and CI health without ever touching my mouse.

Why Bother?

It’s not about being a terminal elitist. It’s about cognitive load. Every time you switch apps, your brain has to re-orient. By staying in the terminal, you keep your context. Your code, your tests, and your project management tools all live in the same space.

The web UI is a great backup, but for the day-to-day "grunt work" of being a developer, the CLI is simply more efficient. Give it a week—your Alt-Tab fingers will thank you.