handle multiple Git accounts professionally

context

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

$ git config --global user.name "Iulian Balan"
$ 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.

[user]
    name = Iulian Balan
    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.

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

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.

$ 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.

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

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

[user]
    name = Iulian Balan
    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.

[user]
    useConfigOnly=true
[init]
    defaultBranch = main
[includeIf "gitdir:~/workspace/heits/"]
    path = .gitconfig-heits
[includeIf "gitdir:~/workspace/personal/"]
    path = .gitconfig-personal
[gpg]
    program = /usr/local/bin/gpg
[core]
    autocrlf = input

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

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

The folder structure must reflect the Git configuration conditional include

/Users/iulian.balan
└── workspace
    ├── heits
    └── 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

Committer: Iulian Balan <iulian.balan@MacBook-Pro-2.local>

Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You 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.

Author identity unknown

*** Please tell me who you are.

fatal: no email was given and auto-detection is disabled

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.