How to keep GitHub Codeowners from getting removed from notifications when one team member reviews the PR

If you’re on a team that has branch protections in place that require more than one pull request (PR) approval, GitHub’s default behavior can cause notifications to be dismissed prematurely. For instance, let’s say a team is assigned to review a pull request, and one team member provides their approval. In this scenario, GitHub dismisses notifications for other team members, assuming that the pull request no longer requires additional review. However, this can be problematic if branch protections mandate multiple approvals. An effective workaround is to have the latest PR reviewer reassign the team for additional review. Yet, this manual process is prone to oversight. So, how can we automate this process?

A solution to this dilemma lies in setting up GitHub’s auto assignment feature. By enabling auto assignment, whenever your team is requested to review a PR, the system automatically removes the team as a reviewer and designates a specified subset of team members in its place. You can include your entire team in this subset to ensure everyone receives notifications without the need for manual reassignment. For detailed guidance on configuring your team’s settings for this automation, refer to the documentation provided here.

Handy Git Commands

Git is a version control system that tracks changes in a set of files, which is used by developers to coordinate work done for various projects. Here are some useful git commands that can help with your workflow:

General Commands

  • git status to see what changes have been made locally
  • git add . to commit all locally edited files in the repo
  • git add <file> to add a file to the next commit
  • git rm <file> to delete a file in the next commit
  • git mv <file> to rename a file in the next commit
  • git add -p is useful if you’ve done too much work for one commit, ? is a useful command to print all
  • git cat-file -p <sha> prints the contents of blobs (sha refers to the SHA or hash that git assigns to each commit)
  • cat .git/HEAD to see what HEAD is pointing to


Stashing your work is useful if you’re moving between branches when you’re in the middle of work. It’s a safe, non-destructive way to save your work.

  • git stash to save uncommitted work
  • git stash list to view the current stashes that are available
  • git stash apply applies the last stash
  • git stash apply stash@{0} to apply a specific stash (in place of the 0 you can add the number associated with the stash from your git stash list that you’d like to apply)
  • git stash --include-untracked to keep untracked files in your stash
  • git stash save "WIP: working on recent bug fix" in place of the text in the quotes here, you can add a name for easy references when viewing the list of your stashes and figuring out which stash to apply on your current branch
  • git checkout <stash name> -- <filename> grabs a single file form a stash
  • git stash show stash@{2} to show the files changed

Keeping Your Stash Clean

  • git stash drop to remove the last stash
  • git stash clear to remove all stashes


  • git log to view an overview of the most recent git commits
  • git log --since="yesterday" to view commits from a specific time period. You can also pass arguments like git log --since="2 weeks ago"
  • git log --name-status --follow -- <file> to log files that have been moved or renamed
  • git log --diff-filter=R --find-renames to find files that have been renamed
  • git show <commit> to show commit and its contents
  • git show <commit> --stat show files changed in commit
  • git show <commit>:<file> look at a file from another commit

Fixing Mistakes

  • git checkout -- <file-path> overwrites the working area file with the staging area version from the last commit (this operation overwrites without warning so use with caution)
  • git clean will clear your working area by deleting untracked files (this operation cannot be undone). Use the --dry-run flag to see what will get removed
  • git reset moves the HEAD pointer, modifies files for commits (can change history)
  • git revert <commit> is the safe reset (creates a new commit that introduces the opposite changes from the specified commit, the original commit stays in the repo)
  • git reset --hard HEAD use this command if your staging area has gotten really messed up and you want to blow away all of your local work
  • git commit --amend if you need to amend your latest commit
  • RERERE (Reuse Recorded Resolution) is a tool that remembers a previously used solution for a merge conflict. Set git config rerere.enabled true within a project to have access to this tool. You can also set it globally with git config --global rerere.enabled true


Rebasing your feature branch with main will help keep your development work up-to-date with the latest changes that have been committed to the repo. This will help make merge conflicts more manageable whenever it’s time to merge in your feature work.

  • git rebase main makes history of current branch cleaner and makes managing merge conflicts easier
  • git rebase -i <commit to fix> addressing specific commits

Working with GitHub

  • git clone <project reference to clone a GitHub repo locally
  • git pull performs a git fetch && git merge to ensure the latest version of a branch has been updated on your machine
  • git push origin <name-of-branch> to push any changes to the remote repo
  • git pull --rebase will fetch, update your local branch to a copy of the upstream branch, then replay any commits you made via rebase (this doesn’t work well on branches with local merge commits, it works best when branching off master and working on a feature)

Local Destructive Operations

When performing a destructive operation, make sure you properly stash your work so you don’t accidentally delete any of your work in progress. Use git stash --include-untracked to include working area changes in your stash.

  • git checkout --<file> if file is presnt in staging, it will be overwritten
  • git reset --hard overwrite changes that are staged and in working area
  • rebase, amend, and reset can rewrite history (if your code is hosted or shared, never run git push -f which forces a push of your changes)

Configuring Your Editor

To customize which editor git opens when you run a commit with no -m flag, a merge, or rebase, run the following command:

git config --global core.editor <your_editor>

In the place of <your_editor>, add the command associated with your editor of choice:

  • atom: atom --wait
  • emacs: emacs
  • sublime: subl -n -w
  • vi: vi or vim
  • vscode: code --wait

Can I Host Multiple Sites with GitHub?

The other day I was looking into hosting websites on GitHub Pages, and I found myself wondering if it’s possible to host multiple custom domains for a single GitHub account. I came to the conclusion that it isn’t possible. You can use one custom domain per account, and that custom domain can effect different types of repositories within your account. For instance, if I used for my custom domain, it would be the new URL used to access my GitHub site page that was previously accessed via Then project pages would no longer have the URL, but would use instead.

So if you want to keep your other repos more separate from your personal page, you may want to rethink how you use a custom domain. Or you’ll possibly want to think about how you’d like to brand your different repositories.

Here are a couple of articles that can help you with linking your domains to GitHub Pages:

View at

Linking Namecheap to GitHub Pages

Deploying a React App to GitHub Pages

Earlier today, I worked on putting together this Sticky Note App, in an effort to get more comfortable with React.js. The application uses React.js, React DOM, and React Draggable.

After completing my application, I was about to tackle deployment with Heroku, since I’ve become pretty familiar with deploying various applications that consist of different stacks on Heroku.

However, this application was a lot simpler, so it seemed like using Heroku would have been a little excessive, especially since there’s no backend component for this application.

So I decided to tackle deploying the application via GitHub pages – which is already one of my favorite ways to deploy simple applications since I host all my repos there as well.

The first step I did, was use the create-react-app command in my terminal, where I then moved the various components of my simple React application. Then I followed the following steps:

Step 1

Edit package.json by adding a homepage

"homepage": "https://[insert username][insert project repo name]"

Step 2

Run npm install --save-dev gh-pages

Step 3

Edit package.json by adding a predeploy and deploy script:

"scripts": {
"predeploy": "npm run build",
"deploy": "gh-pages -d build"

Step 4

Run: npm run deploy

And there you have it, a simple enough solution for deploying those simple enough React applications.