Skip to main content

3 posts tagged with "productivity"

View All Tags

Boost productivity with the GitHub CLI

· 10 min read
Nick Taylor
AI Engineer

The GitHub CLI is an indispensable tool as a project maintainer or contributor on GitHub. It can boost your productivity when getting things done.

Someone's head exploding like the exploding head emoji

The day my brain exploded was when I discovered (spoilers) that you could create a pull request using the GitHub CLI.

Let's get started!

Install the GitHub CLI

Head on over to the installation docs to get the GitHub CLI set up. There are installers for Linux, Windows, and macOS.

Log In to GitHub via the GitHub CLI

You're up and running but if you try to run any commands, you're going to be prompted to log in, so let's do that first.

Trying to execute a GitHub CLI command when not logged in results in the following message, To get started with GitHub CLI, please run: gh auth login
Alternatively, populate the GH_TOKEN environment variable with a GitHub API authentication token.

To log in to GitHub via the GitHub CLI, run gh auth login.

GitHub CLI gh auth login command running

You'll be given two options for logging in. or GitHub Enterprise Server. In most cases, unless your company uses GitHub Enterprise Server, you'll select the default,

Next, you'll be asked which protocol to log in with. The default is HTTPS, but I recommend SSH. To learn more about configuring GitHub with SSH, see Connecting to GitHub with SSH.

Login via SSH

The GitHub CLI prompting with the following, What is your preferred protocol for Git operations? Use arrows to move, type to filter HTTPS or SSH

Next, it will ask you to publish your public key to GitHub. This is safe to do and you can proceed.

GitHub CLI prompting to upload your public SSH key

It will prompt for a title for the key. Using the default value of "GitHub CLI" is fine.

The GitHub CLI prompting for a title for the SSH public key

Login via HTTPS

If you choose HTTPS, you'll be asked to authenticate Git with your GitHub credentials.

The GitHub CLI prompting to log in with your GitHub credentials

Press ENTER to continue.

Finishing Login Process

Next, you'll be prompted to log in via the browser or a token. To be honest, I've never used a token at this step. I always log in via the browser. If you have a token, go for it.

The GitHub CLI prompting to log in to GitHub via a browser or a token

You'll be given a code in the CLI that you need to copy (changed to some code in my screenshot) and then press ENTER to log in via the browser.

The GitHub CLI outputting a code you need to copy to finish the login process

Paste or type in the code and press the Continue button. device activation screen

Next, you'll be asked to Authorize GitHub. Click the Authorize GitHub button.

The authorize GitHub CLI screen on

At this point, depending on how you have the security of your account set up, you may be asked to log in via the GitHub mobile app.

Multifactor confirm access screen using GitHub mobile

Log in via the GitHub mobile app or other multifactor authentication methods you have set up.

At this point, you should be all set up. confirmation screen that the device was connected successfully

And if you go back to the command line, you should see something similar to this.

GitHub CLI confirming that you are logged in

Useful Commands

Let's walk through a couple of commands I use every day, and then we'll check out some other useful ones that I use less frequently.

Reviewing a Pull Request

As a maintainer of a project, you will definitely be reviewing PRs (for external contributors or team members). Before we had the GitHub CLI, I always had to Google how to get someone's PR on my local machine with Git. I forgot all the time, so, at one point, I made a Git alias for it. The command looks like this, git fetch origin pull/pr_number/head:name_of_branch. So if I was going to review pull request 1234, the command would look something like this, git fetch origin pull/1234/head:pr-1234. You can call the branch whatever you want. I used to name it pr- with the number of the PR.

None of that is necessary these days. With the GitHub CLI, all you need to do is cd into the project directory in your terminal and then run gh co pr-number, e.g. gh co 2062

Here it is in action for a recent pull request I reviewed for the OpenSauced app repository.

Running the GitHub CLI checkout command, gh co 2062, to check out pull request 2062 from a repository

Creating a Pull Request

Before the GitHub CLI, I used to push my branch to GitHub, and then I would go to the repository's page on and create a pull request from there.

A repository's main page on with a call to action to create a pull request from a branch pushed to

Although that works, when I discovered that the GitHub CLI could do this, I was blown away. All you need to do is run gh pr create from the command line, assuming you're currently on the branch of the repo you want to associate with the pull request. You can provide additional arguments, e.g. gh pr create --draft or the shorter version gh pr create -d, but typically, when I'm creating a PR, I go through the steps in the CLI and continue the final step in the browser. It's a preference, so do what works best for you.

Here's me creating a new test PR.

Running the GitHub CLI create pull request command, gh pr create, to create a new pull request for a repository

Creating or Pushing a New Repository to GitHub

In the past, I always used to create a new repository from

User menu on open with the menu item New Repository highlighted

I'm sure there is a way to create a repository on GitHub from the command line, but I never bothered to learn it, and now I don't really need to thanks to the GitHub CLI.

Create a Repository from Scratch

To create a repository from scratch, run gh repo create from the command line.

The GitHub CLI prompting user what to do with Create a new repository from scratch selected

Select Create a new repository on GitHub from scratch and press the ENTER key.

Next, you'll be prompted to name the repository, e.g. test.

The GitHub CLI prompting for a name for the repository

Next, choose the repository owner. If you're a part of one or more GitHub organizations, they will appear in the list. For our example, I will go with my own account, nickytonline as the repository owner.

The GitHub CLI prompting for a repository owner

Add a description for the repository, e.g. test or leave it blank. It's not required.

The GitHub CLI prompting for a description

Next, set the visibility of the repository. It can be public (default), private, or internal.

The GitHub CLI prompting for the visibility of the repository

Since this is a test repository, I'm going to set it to private.

The GitHub CLI running with privacy selected for the visibility

Next, you'll be asked to create a README file. Type y and press the ENTER key.

The GitHub CLI prompting to create a README

You'll be prompted to add a gitignore file. Type y and press the ENTER key.

The GitHub CLI prompting for to create a gitignore file

Next, choose the language that will best reflect the contents of the gitignore file. I do a lot of JavaScript, Node.js and TypeScript, so I'm going to choose Node.

Node selected as the language for the gitignore template

You'll be asked to add a license. Type y and press the ENTER key.

The GitHub CLI prompting to create a license

Choose the license that makes the most sense for the project you're creating. For the purposes of this blog post, I'll choose the MIT license.

MIT License selected in the GitHub CLI

A quick check will ask if you want to create the repository on GitHub. Type y and press the ENTER key to proceed.

The GitHub CLI summarizing all the selections made, prompting the user to create the repository on GitHub

Next, you'll be asked if you want to clone the repository locally.

The GitHub CLI asking the user if they want to clone the repository

Type y and press the ENTER key to proceed.

The new repository is on now and has been cloned on your machine.

Push an Existing Local Repository to GitHub

To push an existing local repository to GitHub, run gh repo create from the command line.

The GitHub CLI, with the Push an existing local repository to GitHub option selected

You'll be prompted for the path to the local repository. It defaults to ., the current directory. If, for some reason, you ran the command outside your local git repository folder, specify the folder to your repository.

The GitHub CLI prompting to enter the path to a local repository

Next, you'll be asked to name the repository. By default, it will use the name of the folder the local repository resides in, e.g. test. Change it if it makes sense to.

The GitHub CLI, prompting a user to enter a repository name

Next up, you're prompted to select a repository owner. By default, it's your user, e.g. nickytonlin, but you can select any organizations you're a part of as well.

The GitHub CLI prompting for a repository owner

Next, you'll be asked to add a description. You can add one or leave it blank. It's up to you.

The GitHub CLI prompting for a description for the repository

Next, you'll be asked to set the visibility of the repository. It can be public (default), private, or internal.

The GitHub CLI prompting to select the visibility of the repository

Next, you'll be asked if you want to set a remote. Press enter to say yes (the default)

The GitHub CLI prompting to add a remote for the repository

You'll be asked what the new remote should be called. Press the ENTER to accept the default name of origin. The GitHub CLI notifies you that the remote has been added, e.g.

The GitHub CLI prompting to name the remote

And finally, you'll be asked if you want to push the commits from the current branch to the origin remote. Press the ENTER key to push the commits, and you're done!

The GitHub CLI pushing the current branch to the origin remote on GitHub


For myself, the GitHub CLI has become a game changer in my day-to-day workflow. I literally use it every day, well, work days. 😎

From creating a new repository, to pulling down a pull request (PR) to creating a PR and more, the GitHub CLI has become indispensable to me.

There is a whole other set of commands available in the GitHub CLI that I encourage you to check out and that, to be honest, even I should explore further.

I realize not everyone is comfortable with the command line, but I think that if you give the GitHub CLI a chance, you may grow to love it. As always, though, use the tools that make you the most productive.

Stay saucy peeps!

If you would like to know more about my work in open source, follow me on OpenSauced.

GitHub Actions: A Maintainer's Best Friend

· 4 min read
Nick Taylor
AI Engineer

As developers, it’s in our best interest to automate things. The less we have to do in a manual way, the better. As soon as manual intervention is required, there is potential for failure or a mishap. Aside from that, it’s your time as a maintainer that could be spent elsewhere.

If you host your code on GitHub, besides scripts to automate certain actions, you can also leverage the huge ecosystem of GitHub Actions.

Practical Examples

Let’s look at some practical examples of GitHub actions helping maintainers.


If someone opens an issue on your repository, you could respond with a personal message saying thank you, but those keystrokes are probably better suited for other things. Automate a message reply instead, thanking the community member for creating the issue and mentioning you will look into it. An automated message to the issue opener is friendly, even if it’s automated.

A great GitHub action for this is Peter Evans’ Create or Update Comment action.

It’s used in the app repository for OpenSauced. Here’s how we have it configured.

When a new issue is opened, an issue responds with the following:

Automated comment when an issue is created in the OpenSauced App repository that says "Thanks for the issue, our team will look into it as soon as possible! If you would like to work on this issue, please wait for us to decide if it's ready. The issue will be ready to work on once we remove the "needs triage" label. To claim an issue that does not have the "needs triage" label, please leave a comment that says ".take". If you have any questions, please reach out to us on Discord or follow up on the issue itself. For full info on how to contribute, please check out our contributors guide."


My coworker bdougie (@bdougieyo) created the take Github action. It allows external contributors to self-assign issues by typing .take into a comment of an issue. This removes the burden of a bit of back and forth between contributors and maintainers.

OpenSauced contributor itskish0re self assigning an issue by using the .take command

Of course, we don’t want external contributors self-assigning any issue they want. The take action also has the concept of blocking labels. For example, if an issue has a 👀 needs triage label, we can add this label to a list of blocking labels.

Someone trying to self-assign an issue when there are blocking labels on the issue


Another action that came onto my radar a couple of days ago was thanks to styfle. Although I haven’t used it yet, nissuer looks like a great utility belt GitHub action for maintainers. The Next.js repository uses it, so I'm sure it brings lots of value to a maintainer.

I love this note they added in the README.

NOTE: Developers are coming to your project with all sorts of backgrounds/skill levels or understanding of the open-source world. Show empathy while using this action. 💚 We recommend adding comments that not only dismiss unhelpful issues/comments, but educate the user on how to be more helpful in the future.

Bespoke Actions

Don’t see a GitHub action for what you need? Create your own. You can even build your own by composing it from existing GitHub actions. Here's an example of a bespoke workflow I use for pulling in my latest video content from YouTube to my blog.

I'm using some GitHub Actions, a custom script that leverages the GitHub CLI and magic.

{% raw %}
name: Get latest videos
# Everyday at midnight UTC
- cron: '0 0 * * *'

name: Get latest videos
runs-on: ubuntu-latest
- uses: actions/checkout@v2
- uses: actions/setup-node@v3
node-version: 18
- name: Get latest videos
run: |
npm install
node bin/udpdateStreamingPage.js
- name: Setup git config
run: |
git config 'token-generator-app[bot]'
git config '82042599+token-generator-app[bot]'
- name: PR for Videos
run: |
{% endraw %}

You can see the results on the streaming page of my site.

The post is a bit out of date, but I discuss more in depth the automations for my website in


These are just examples of tasks you can automate, and if you’re using GitHub, there is a huge ecosystem of GitHub actions to help with your automation goals.

What are some GitHub actions that you’ve leveraged in your projects? Share them in the comments.

Stay saucy peeps!

If you would like to know more about my work in open source, follow me on OpenSauced.

Supercharge your Repository with Code Owners

· 3 min read
Nick Taylor
AI Engineer

As a maintainer of a repository, it’s in your best interest to automate processes as much as possible. The CODEOWNERS file is one of those tools to help with automating processes.

I decided to write a post about the CODEOWNERS file after reading this comment from one of our awesome Octerns, Divyansh (@diivi), in a pull request (PR) where I added the file.

GitHub user diivi commenting that they weren't aware of the CODEOWNERS feature

A CODEOWNERS file in GitHub is a special file used to specify who reviews and maintains specific files or directories in a repository. It helps with identifying code ownership and who should be notified when pull requests are made to those repositories.

For example, in this particular CODEOWNERS file there is the @open-sauced/engineering team.

A CODEOWNERS file with one team in it, @open-sauced/engineering

When someone creates a PR for that repository, that team is automatically added as a reviewer.

Reviewers for a PR in the GitHub UI including the @open-sauced/engineering team

This is really handy because you don’t need to go and manually add reviewers, and when it’s a PR from an external contributor, they can’t add reviewers so this is super useful for them and can avoid comments like, “Can someone review my PR?”

Another nice feature of the CODEOWNERS file is that it can be used as part of branch protection.

To enable this, go to the Protect matching branches section of a branch protection rule, and ensure the Require review from Code Owners option is checked.

GitHub PR review file where the UI says that the CODEOWNERS file is valid

One other thing to note is if you have permanent branches aside from main, like beta, dev, or whatever your team calls it, they can have different individuals and teams in those branches CODEOWNERS file.

How to add a CODEOWNERS file to your project

The CODEOWNERS file is a special file that can reside in the root directory, in the .github directory or the docs directory (if you have one).

The .github folder might not exist in your project if you haven’t added other GitHub automated processes like GitHub Actions, pull request templates, or issue templates.

Also note, GitHub looks for the first CODEOWNERS file it finds, searching first in the root directory, then the .github directory, and finally, the docs directory (if it exists).

You can add individual GitHub users, a team, or a combination of them to a CODEOWNERS file.

A CODEOWNERS file with teams an individuals in it

A nice feature of adding or making changes to a CODEOWNERS file in a pull request is that GitHub validates it, letting you know if you are adding a non-existent user or team.

Image description

If you don’t already have a CODEOWNERS file file in your repository, I encourage you to add one. Let us know if you have any questions about this or other maintainer-related issues.

Stay saucy peeps!

If you would like to know more about my work in open source, follow me on OpenSauced.