Blog.

Globally configure multiple git commit emails

Marco Franssen

Marco Franssen /

4 min read746 words

Cover Image for Globally configure multiple git commit emails

Have you ever been struggling to commit with the right email address on different repositories? It happened to me many times in the past, but for a couple of years I'm now using an approach that prevents me from making that mistake. E.g. when working on your work related machine, I'm pretty often also working on Opensource in my spare time, to build my own skills, and simply because I believe in the cause of Opensource. Also during work time I'm also sometimes contributing fixes back to Opensource projects we are using, for those times I want to commit using my work email address when committing. You can imagine it is a hassle to continuously think about using the correct email address when committing. In this blog I will be sharing a really simple solution to that.

I will assume you are configuring this on your work machine, in case you would like to apply similar on your personal machine, ensure to do the opposite of my suggestions.

Configure your git user globally

First of all ensure you configure your git user globally using your companies email address. You can do that by using following command.

terminal
git config --global user.name "Marco Franssen"
git config --global user.email "[email protected]"

Using this setting all repositories you clone or create on this machine will use this user information to commit. So what about working on private projects from this machine?

Configure alternative settings for private projects

To work on private projects I came up with a folder based approach that allows me to configure git in the global configuration file ~/.gitconfig to use different user information for projects in a specific folder. In my case I have all my code in a ~/code folder, and for personal projects I choose to put them in ~/code/priv. See following terminal output for an example.

terminal
$ tree -L 3 code
├── priv
│   ├── blog
│   ├── helm
│   ├── kubernetes
│   └── spire
├── spire
├── helm
├── work-project-a
├── work-project-b
├── work-project-c
└── work-project-d
 
9 directories, 0 files

Now when working in my private time I work on the repositories from the ~/code/priv/… folders. When working in my company time I work on the projects outside of the ~/code/priv folder. This also allows me to easily contribute to opensource projects using my company email address. Only downside is that some projects are cloned twice. I did try with symbolic links to get rid of this downside, but unfortunately that didn't seem to work.

Now to enable globally to commit with my private email address when working within the ~/code/priv/… folders I create another git config that I can conditionally include in the global config.

git config --file ~/.gitconfig-private user.email [email protected]

This will result in the following ~/.gitconfig-private file.

terminal
$ cat ~/.gitconfig-private
[user]
    email = "[email protected]"

You could also put other overrides in this configuration file. E.g. you want to use a different GPG key for private contributions.

Now this is where the magic is going to happen. In our global config we want to add the conditional statement that includes our new ~/.gitconfig-private that overrides the global settings when in a particular folder on your system using the ones defined in ~/.gitconfig-private.

We can do that using following command.

terminal
git config --global includeIf."gitdir:~/code/priv/**/*".path "~/.gitconfig-private"

This will result in the following ~/.gitconfig file. (omitting here any other configs you might there)

terminal
$ cat ~/.gitconfig
[user]
    name = "Marco Franssen"
    email = "[email protected]"
 
[includeIf "gitdir:~/code/priv/**/*"]
    path = ~/.gitconfig-private

Recap

Using the following global git configuration we will by default commit all our code using our work email address except for the code located within ~/code/priv. If you wanted to do the same on your personal machine you might want to do the inverse (~/code/work and then configure globally your private email and override with your work email).

This is how the entire config looks like (omitting any other configurations you might have applied).

terminal
$ cat ~/.gitconfig
[user]
    name = "Marco Franssen"
    email = "[email protected]"
 
[includeIf "gitdir:~/code/priv/**/*"]
    path = ~/.gitconfig-private
 
$ cat ~/.gitconfig-private
[user]
    email = "[email protected]"

For more information on conditional includes see the Git documentation.

You have disabled cookies. To leave me a comment please allow cookies at functionality level.

More Stories

Cover Image for OCI as attestations storage for your packages

OCI as attestations storage for your packages

Marco Franssen

Marco Franssen /

In my previous blog you can read about securing the software supply chain for Docker images using GitHub actions and Sigstore. We have seen how we can sign our Docker images, as well how to generate an SBOM and build provenance. Using Sigstore/cosign we attached both the signature, SBOM and build provenance to the Docker image. Using Sigstore we get a real nice integration and developer experience to add these security features to our build pipelines for Docker images. In this blog I want to sh…

Cover Image for Secure your software supply chain using Sigstore and GitHub actions

Secure your software supply chain using Sigstore and GitHub actions

Marco Franssen

Marco Franssen /

With the rise of software supply chain attacks it becomes more important to secure our software supply chains. Many others have been writing about software supply chain attacks already, so I won't repeat that over here in this article. Assuming you found my article, because you want to know how to prevent them. In this blogpost I want to show you how to secure the software supply chain by applying some SLSA requirements in the GitHub actions workflow. We will utilize Sigstore to sign and attest…

Cover Image for Gitops using Helmsman to apply our Helm Charts to k8s

Gitops using Helmsman to apply our Helm Charts to k8s

Marco Franssen

Marco Franssen /

In my last blog series I have shown an example of deploying Hashicorp Vault on Kubernetes using Helm Charts (see references). This time I want to show you how to more easily integrate this into your … wait for it … :smile:, DevSecGitOps flow. Especially Helm charts help a lot in connecting the software part with our infrastructure / deployment (DevOps). Besides that we can embed all kind of security practices in our Helm charts like for example RBAC, Network policies etc. In this blog I want to…

Cover Image for Install Hashicorp Vault on Kubernetes using Helm - Part 2

Install Hashicorp Vault on Kubernetes using Helm - Part 2

Marco Franssen

Marco Franssen /

In part 1 we had a look at setting up our prerequisuites and running Hashicorp Vault on our local Kubernetes cluster. This time we will have a look at deploying Hashicorp Vault on a EKS cluster at AWS. This time we will deploy a Vault cluster in High Availability mode using Hashicorp Consul and we will use AWS KMS to auto unseal our Vault. First lets have a look at the new tools we are about to introduce. If you didn't read part 1, you might consider reading that first to get a bit more underds…