Improving my Zen with GitHub

It's 17:00 on a warm Friday evening. As you type the final characters into your PR description, your mind drifts to the coming weekend. During that weekend, you decide to work on that open-source you cloned a while back, so you head to GitHub to look through the open issues. Like many developers, you use the same GitHub account for both your personal and work projects, so when you open GitHub, you can't avoid seeing that a colleague has spent some of their weekend leaving comments on your PR. You're now faced with a dilemma:

A. Open your PR and read those comments.

Or

B. Try to ignore those comments.

Choosing A means that you spend a portion of your weekend completing work-related tasks when you should be relaxing and recharging. Do this too often, and those out-of-work tasks you are completing will lead to your in-work performance dropping and may even lead to you burning out.

Choosing B means that throughout the rest of the weekend, you repeatedly return to that PR in your thoughts, wondering what issues someone found in your solution. Not knowing what someone has commented on can be low-level stressful. This stress is because, as humans, we are programmed to remind ourselves about any uncompleted tasks. Your colleague leaving comments means that your previously completed task is now incomplete. In psychology, this is known as the Zeigarnik effect and will stop you from leaving work behind to focus on whatever you are doing during the weekend.

As you can see, choosing A or B leads to a negative outcome. The only way to truly enjoy your weekend is to leave work behind. In this case, what you don't know can't hurt you.

Having my mixed GitHub account kept stressing me out. I couldn't help but see work-related updates on the GitHub homepage while doing some recreational programming. I don't want to stop the recreational programming because I love it, but I couldn't let my mental health continue to suffer. The only way I could prevent this unneeded stress was to disconnect my personal and work GitHub usage by creating multiple GitHub accounts.

However, creating and using multiple GitHub accounts on the same computer proved to be slightly trickier than I thought it would be.

Adding multiple accounts

After creating a work-only GitHub account, I needed to generate an SSH key so that I could access that account from my machine. The only difference from the documented Git setup is that I couldn't use id_rsa as the file name to store my work account's SSH key (as it was storing my personal SSH key) instead I had to use a different name, i.e. id_rsa_work.

Now that I had both SSH keys on my Mac, I needed a way to inform Git which one to use with each repository.

There are numerous detailed articles already written on this subject, and I ended up with an SSH config (~/.ssh/config) of:

Host personal
  HostName github.com
  User git
  AddKeysToAgent yes
  UseKeychain yes
  IdentitiesOnly yes
  IdentityFile ~/.ssh/id_rsa

Host work
  HostName github.com
  User git
  AddKeysToAgent yes
  UseKeychain yes
  IdentitiesOnly yes
  IdentityFile ~/.ssh/id_rsa_work

When cloning a repo, I would specify which account to use, and any actions after on that repo would happen as that account, i.e.

git clone personal:wibosco/CoreDataServices.git

or

git clone git@personal:wibosco/CoreDataServices.git

However, sadly, I wasn't able to make this work on my Mac (Mojave or Catalina). No matter how I manipulated the structure of my SSH config, I ended up back at the same issue: Git always attempted to use the last key added to the SSH Agent, regardless of which account I specified when cloning the repository.

Just as I started to despair that there was no way to get this working, the thought occurred to me:

"Well, if SSH Agent is always serving the last key added I can just only tell it about the key for the account I want to use"

If the SSH Agent only knew about one SSH key, that key was the one it would serve.

So the first thing to do is make the SSH Agent forget about my personal and work SSH keys by removing them:

ssh-add -D

Once all SSH keys were removed (from the Agent, not the system) I could then add the correct key for the repo I wanted to access, so if it were a personal repository, I would add my personal key to the SSH Agent:

ssh-add -K ~/.ssh/id_rsa

Then, when I used any Git commands, they would be executed as my personal account. If I wanted to use my work account, I would remove the personal key and add my work key. While it was annoying having to keep switching between accounts, it worked!

Executing ssh-add -l shows you which keys are loaded.

Even with the inconvenience of having to manually add and remove keys from the SSH Agent, I was able to improve my work-life balance by eliminating the general sense of unease I would experience when avoiding work-related updates during my personal time. I don't have any data on how this change impacted my productivity, but I imagine it has improved it.