Handle multiple Git accounts professionally

If you're working in the software development industry, it's almost a certainty that you had to work with Git, the famous distributed version control.

After downloading it, the common suggested action is to set up your credentials

1$ git config --global user.name "Iulian Balan"
2$ git config --global user.email "[email protected]"

Here, you can see that I've configured Git, globally, to use my name and my work email, for every repository that I will be working on. You can also add or edit this information manually in ~/.gitconfig.

1[user]
2    name = Iulian Balan
3    email = iulian.balan@heits.digital

Now, what happens if I have another account, using my personal email? How do I configure Git to be able to distinguish my work projects from my personal ones?

Well, there are multiple ways to achieve this, and I'll try to showcase only two of them

• configure every individual personal repository with the new credentials.
• create some sort of convention and a one time global configuration.

Let's take a closer look at these options and compare them.

Per repository override

As you can probably tell from the title, this option implies the usage of local configurations. Git supports custom configurations per repository and to do this, we can just remove the --global flag from the initial command and run it in the target repository. And that's it.

1$ git config user.email "[email protected]"

Pros

• clear and easy to implement

Cons

• we have to do it for every repository that we want to override, and we might forget. This will cause a commit and push with the wrong credentials.
• we might need to add some scripting to be able to easily add additional settings.

One time global configuration

Starting with version 2.13, Git introduced a conditional include called includeIf. We can use it to include a config file from another one, conditionally. Let's modify the global ~/.gitconfig to test this.

1[includeIf "gitdir:~/workspace/heits/"]
2    path = .gitconfig-heits

And our ~/.gitconfig-heits file is just another Git config file

1[user]
2    name = Iulian Balan
3    email = iulian.balan@heits.digital

Now, if we create a new repository inside ~/workspace/heits/ (the trailing / is automatically interpreted by Git as ** wildcard), the custom configuration inside .gitconfig-heits will be used.

We can extend this approach to use how many configurations we want. My final config files look something like.

1[user]
2    useConfigOnly=true
3[init]
4    defaultBranch = main
5[includeIf "gitdir:~/workspace/heits/"]
6    path = .gitconfig-heits
7[includeIf "gitdir:~/workspace/personal/"]
8    path = .gitconfig-personal
9[gpg]
10    program = /usr/local/bin/gpg
11[core]
12    autocrlf = input

And individual configurations can be like the snippet below. I omitted the .gitconfig-personal because it's essentially the same.

1[user]
2    name = Iulian Balan
3    email = iulian.balan@heits.digital
4    signingkey = <GPG-KEY-HERE>
5[commit]
6    gpgsign = true

The folder structure must reflect the Git configuration conditional include

1/Users/iulian.balan
2    └── workspace
3        ├── heits
4        └── personal

Disable Git's option to infer name and email

By default, if name and email are not set Git is configured to infer them from the local machine. If we try to commit in a repository that is outside the configured paths, Git will allow the commit, but it will output a warning like the following

1Committer: Iulian Balan <iulian.balan@MacBook-Pro-2.local>
2
3Your name and email address were configured automatically based
4on your username and hostname. Please check that they are accurate.
5You can suppress this message by setting them explicitly

This is something that we don't want to push to origin and to disable this behavior we can use the property useConfigOnly set to true added to the global Git config. This will instruct Git to reject our commits if the identity is not set. Here is the error message in case we try to do it anyway.

1Author identity unknown
2
3*** Please tell me who you are.
4
5fatal: no email was given and auto-detection is disabled

To summarize

Pros

• one time configuration
• can easily be expanded for each type of use case, not account specific only
• we don't need to remember to configure new repositories
• automatically reject commits in a different folder than the ones we configured

Cons

• can be a bit more complex at the beginning, but that's why we are developers and, because we love challenges.

Conclusions

You can use whatever configuration suits you the most. Knowing myself, I will probably forget to set the correct email, especially when working with tens of repositories.

But having the possibility to customize Git based on the repository's base path, gives me more control with less burden. The only thing that I need to make sure is where I create/clone a new repository.