Skip to main content

Git, GitHub and your work email

A setup to separate private and work-related contributions on Github

Β· 5 min read
Max Mulatz

A possible setup for separating private and work-related contributions on GitHub: associate commits with your "private" vs. your "work" email.

GitHub being such a convenient place to collaborate on software, it's likely that both, work and "leassure coding" take place on the same platform. Do you need two separate accounts for both activities? Eventually yes… But to spare the hassle of switching accounts back and forth and remembering to actually do that, a lot of people - including myself - prefer to use a single account (as long as this is legally aligned with your work place). However, aside from keeping that yin-yang of a work-life-balance, fully blending in your work-related coding into your private ramblings on GitHub and vice versa feels wrong from multiple angles, mainly the legal one. In which role did you contribute this piece of code, who "owns" this contribution now? You, your employee, a client?

So a bit of separation can come in handy. But how to get there without juggling accounts? Say hi to your old friend from the 80s: email πŸ“§

Different to what one would expect on first glance, GitHub does not directly associate contributions with accounts. It's rather just "connecting" the contribution to the account that happens to own the email address associated with a Git commit ΒΉ. Listen to the GitHub Ate My RΓ©sumΓ© episode of The Bike Shed podcast for some wild situations this can bring…

It's probably save to assume most people have a dedicated email address for work. Using your private email address for work-related communication uncomfortably stresses the yin-yang and should be avoided. And since we're already there, why not apply the same email hygiene to your commits? Use your work email address for work contributions and your riotcat1991@smthng address for your private coding adventures.

Here are some tips how I set this up for myself. Disclaimer: people are different. While this works fine for me, other solutions may eventually work better for you - find what feels comfy 🧘.

Git Config βš™οΈβ€‹

The setup mainly lives in the gitconfig files in my home directory:

~/
β”œβ”€β”€ .gitconfig
β”œβ”€β”€ .gitconfig_personal
└── .gitconfig_work

Gitconfig​

In .gitconfig, set a name via user.name and deliberately not configure any email address in user.email. I combine this with setting user.useConfigOnly to true:

Instruct Git to avoid trying to guess defaults for user.email and user.name, and instead retrieve the values only from the configuration

Recent versions of Git don't allow to commit without having a name and email address configured for the repository. The email address is an integral part of a commit. By not configuring one globally and instructing Git to not magically figure one out itself, I can avoid accidentally committing with the "wrong" email address.

With this configuration, I now have to manually set user.email for every repository. For convenience, I have two alias set up for this:

[alias]
personal = "config user.email 'me@private.internet'"
work = "config user.email 'me@work.internet'"

Inside a Git repository, running git work configures the email to be used for commits in that repository to my work address.

Directories​

In most cases, it's obvious which email address I want to use. On disk, my projects are organized in a folder structure like this:

~/code/
β”œβ”€β”€ work/
β”‚ β”œβ”€β”€ client_a
β”‚ β”‚ β”œβ”€β”€ projetc_a
β”‚ β”‚ └── projetc_b
β”‚ β”œβ”€β”€ internal
β”‚ β”‚ β”œβ”€β”€ project_c
β”‚ β”‚ └── project_d
β”‚ └── client_b
└── personal/
β”œβ”€β”€ project_a
└── project_a

In my .gitconfig file I include private or work-related additional configuration depending on the directory path of a repository:

[includeIf "gitdir:code/personal/"]
path = ~/.gitconfig_personal
[includeIf "gitdir:code/work/"]
path = ~/.gitconfig_work

These personal and work sub-configurations only configure user.email. For example:

# .gitconfig_personal
[user]
email = me@work.internet

This spares manually running git work or git personal in every repo. Cloning a new project at work into a subdirectory of ~/code/work, the configuration already tells Git to use my work email.

GitHub πŸ™β€‹

Your work email needs to be added to your GitHub account: https://github.com/settings/emails

GitHub UI​

Merging pull requests in the GitHub UI or accepting change suggestions also creates a commit. Similar to Git itself, GitHub doesn't associate commits with your account, but associates the account via the email address the commit is made with 🀯. For UI interactions, this is a bit tricky to get right.

On the first UI interaction in a repository, GitHub shows a dropdown to select the email address to use for the resulting commit. It then stores this email address for that repository and continues to use it for all UI interactions without showing a dropdown to change it ever again. This means, after having used the wrong email once, it is a bit hard to get out of this again.

I already reached out to GitHub support for this problem, but they could not help me. For now, the only "hack" I found to switch the email again is to:

  1. Go to the respective repository
  2. Click on the πŸ–Š icon to edit a file (e.g. README.md) in the web editor
  3. You can choose your email again from a dropdown when commiting
  4. GitHub will continue to use this email from now on for this repo

Disclaimer: this email juggling in the UI is what worked for me back then, it may already be different now.

References​

  • 1: https://docs.github.com/en/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address#about-commit-email-addresses
Max Mulatz

Max Mulatz

Whitespace wrestler on a functional fieldtrip

We're hiring

Work with our great team, apply for one of the open positions at bitcrowd