Introduction

Picture this: you’re working on two git repositories - one for your work and one for your private projects. It’s late, and you’re tired, but you decide to make one last commit before calling it a night. You quickly type in your user data and hit enter, only to realize the next day that you’ve used your private email for a work-related commit. Your boss sends you a confused email, and you spend the rest of the day scrambling to fix the mistake. If only there was a way to avoid this kind of mix-up altogether. Enter GPG signatures, the superhero of git management.

By setting up a global configuration with gpgsign and using scripting to set up gpg id and user data for each local clone separately, we can eliminate human error and ensure that we set up each repository correctly.

Setting up GPG Signatures

GPG signatures are used to sign each commit cryptographically so that the origin is verified.

If this topic is new to you you may wnat to look into how to create GPG keys and how to list the keys on your keyring.

in order to create a gpg key you can use the following command:

gpg --full-generate-key

This will guide you through the process of creating a key. You can also use the following command to list the keys on your keyring:

gpg --list-secret-keys --keyid-format=long

if you have GPG keys that are not on your keyring you can import them usign the following command:

gpg --import <keyfile>

Once you know you have the keys you need you can set them up in your git servive (github, gitlab, etc.)

This is well documented on the respective git service documentation pages. github and gitlab are good examples.

Setting up the Global Configuration

The one thing your global configuration should not contain for this is user information. Instead it should be mostly enough to have a single key in it:

[commit]
        gpgsign = true

You can set this using git config --global commit.gpgsign true from this point on none of your commits can be done without using a gpg key to sign for it. You can test that locally since commit is not pushing to your remote.

Note that the error message would be something like gpg failed to sign the data.

Setting up the Local Configuration

In essence you want to set three things in the local configuration:

• The user name
• The user email
• The signing key

Doing this manually is error prone. It is best to create a script that does it. I prefere to generate an alias to do the heavy lifting for me, this way I can use autocomplete to run these commands.

alias git_set_private='git config user.signingkey EFDC4071BDD65A90840DAF8D4999AD63DA6F99C;git config user.email Josh@test.net;git config user.name Joshinator; cat .git/config'

alias git_set_company='git config user.signingkey 9EBC71165B9BD81582B2537E4890EF2C869C7048;git config user.email J1337@company.com;git config user.name "Serious, Josh"; cat .git/config'

The chance for error is minimal now. You can also use this to set up the user data for a new repository.

Benefits

• Prevents unsigned commits: GPG signatures ensure that every commit is signed, preventing unsigned commits and guaranteeing the authenticity of each commit.

• Avoids confusion and errors: With GPG signatures, each repository’s user data and keys can be set up independently, eliminating the risk of confusion and potential errors. Like using private user data for work-related repositories.

• Increases productivity: By using a script or alias to set up user data, you will save time and avoid human error. The piece of mind that comes with knowing that you are using the correct user data and keys will also increase productivity.

• Scalable solution: The use of GPG signatures can easily be extended to manage multiple repositories and systems without worrying about confusion or errors, making it a scalable solution for managing multiple git repositories for different stakeholders.

Limitations

This approach is not fully compatible with a local demo sandbox for git. When setting up git repositories to demonstrate multiple git repos in a local setup you will need to set the gpgsign to false in the local config. This is because the gpgsign is a global setting and will be used for all local repositories. This is not a problem for the remote repositories since they will have their own local config.