Signed commits and local Github multi-accounting

There was a time when cryptic sysadmins and developers integrated their scripts and codes underneath a pile of skull and rocks (kindly called Revision Control Systems).

Times passed, and after the plume of dust and smoke succeeding the meteor impact dissipated, new systems came to fruition aiming to save the last remnants of living dinossaurs who dared to still keep facing an screen and handling a keyboard - sometimes even using a mouse! - non-stop.

Evolved offsprings filled the earth, and rapidly became popular and known by their own names, like Subversion and TurtoiseSVN, the later its GUI implementation. Things were gaining traction back then, and the fast-paced rhythm on which software was being developed, spawned a new set of demon capable of spread havoc and anxiety for generations to come. Well known as Git.

Loved and hated, different tastes contributed evenly to what’s better abstracted today as source-control management (SCM) creating a rich and diverse ecosystem of tools for the occultist craft of software engineering.

In my life, I’ve only used two systems for source-control management, SVN and Git, so I wanted to give it the propper attention it deserves (Github in this case) because I’ve seen many organizations using it over the years, and people scratching their heads to be more productive while trying to avoid IT Security directives for a safer environment.

Disclaimer: I’m not trying to delve into this subject as there are a lot of useful resources and also an de facto industry standard book written about what git is and how to better leverage its system’s functionality. If you want to go deep, just give it a try!

My main concern that prompted me to write this post is because there’s so much information out there about starting point git configurations, and a lot is missed even for large orgs when they try to implement base guidelines for starters.

My goal is simple, and centered on two milestones :

Signing posts is the most overlooked component when you are working for a closed doors org if they enforce self-domain usage for contributors in private repos, that is: only users with email user@myorg.com are able to contribute on private repositories and no outside collaborators are allowed.

That works - in parts! Let’s suppose you have started small and gaining traction month by month, either in revenue and corporate growth, but also in collaborators among your team who constantly push changes to production. Once you start adding complexity in your environment, and aren’t able to assess broad aspects of individual skill sets of your team members beyond the limit scope of your product needs and engineering interactions - neither are inclined to spend large bucks with security software for everyone’s laptops - so a couple of questions arise:

With these concerns at bay, a preliminary solution is to activate signed commits.

As this post from the old is explaining, it poses a question of authenticity and integrity, because:

Sufficient to say, it also puts another layer of trust in commits inside your org, validating contributions from its members.

So, how do you do that?

I’ll summarize the main steps below, but feel free to check this doc from Github and follow at your own pace.

The process above can be used to generate as many keys as you want. It’s useful if you plan to manage more than a single account on your machine/session, as we’ll cover in the next part.

From now on, you’re able to effectively prove yourself and sign every commit you make. Welcome to surveillance capitalism!

Chances are you’ve already lost at least 5 seconds of your life starring at the above diagram. I really appreciated your taste!

So, when using git on an account in a computer, you could have a virtually unlimited number of git accounts configured if you observe some tricks. But often, the most sought after feature is to maximize productivity, allowing you to commit to your professional projects, and your personal or open-source ones (thanks if you do the later).

The steps below will either work if your needs are the former, or if you want to apply a different kind of use to your accounts. Keep reading.

What the image above says, is that in some cases, you want to use your personal username to work for your org, but using the org. domain email, while trying to preserve this username and your personal email adress for your projects, also. But…​ is that possible? Yes, my defossilized sapiens!

Let’s do that now:

After confirming your address, let’s go to your .gitconfig settings in your machine.

In this step, you’ll not need to configure your SSH keys for each account, as the username will not change. For possible iterations of the contrary, you could check this ancient scroll.

We are going to generate and use two additional files for this case, despite the .gitconfig file, and also will specify an static working path dir, to be used with one of the accounts (my personal taste favors the use for the professional account).

In the .gitconfig file you’ll have your path choice set and additional commands:

One thing to notice in the above configuration is that you can use more than one signing key, or use the same to signed-commit in both projects - make sure your boss don’t work two part-time jobs, if you’ll just one key btw.

If you’re taking advantage of this pandemic and working more than one all-remote job, you could negotiate to use your same username and enjoy a multi-org config. Just create more .git-professional# files and more [includeIf] entries.

That’s it.