Tools
Handle multiple Git accounts professionally
~ 7 minute read
Iulian Balan
Senior Software Engineer
23 Nov 2022
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]"
3
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 = [email protected]
4 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]"
2 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
3 And our ~/.gitconfig-heits file is just another Git config file
1[user]
2 name = Iulian Balan
3 email = [email protected]
4
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
13 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 = [email protected]
4 signingkey = <GPG-KEY-HERE>
5[commit]
6 gpgsign = true
7 The folder structure must reflect the Git configuration conditional include
1/Users/iulian.balan
2└── workspace
3 ├── heits
4 └── personal
5 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 <[email protected]>
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
6 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
6 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.
Written by
Iulian Balan
Senior Software Engineer
Share this article on
