Supporting Multiple Git Repositories

A major element of the consulting that I undertake requires me looking at multiple companies systems. The vast majority of those companies are now using GitHub as their source repository, which has certainly made access somewhat easier, but as the number of companies grows, keeping track of credentials can become an issue.

As I discussed in a previous post (here), accessing multiple repositories, often with multiple distinct credentials is achievable using SSH. But, as the number increases, I found myself constantly having to refer back to the SSH configuration file to remember the correct incantation to access repositories.

There had to be an easier way…

Git Configurations To The Rescue

Applying a small amount of structure to the code, and then performing some magic with git configurations can dramatically simplify the challenge of accessing multiple repositories.

In just three simple steps, a sense of control can be achieved:

1. Create the folder hierarchy with one folder per organisation
2. Add an organisation specific Git configuration at the root of each organisation’s folder
3. Create a global Git configuration at the root of the hierarchy that contains the conditional configuration settings.

Step 1 – Create the Directory Hierarchy

The directory hierarchy is a fairly logical structure requiring each organisation to exist in its own distinct directory. Each organisation, for the purposes of this example represents a GitHub repository. For example:

~/code/
    personal/
    work/
    opensource/
    company a/
    company b/

The actual names for each directory is a matter of personal preference, just make it clear for yourself.

A final note on the hierarchy, if the organisation has multiple hosts, GitHub and AWS CodeCommit for example, these will have to be treated under separate directories. Where I have encountered this, I have set up directories named ‘Company X’ and ‘Company X – AWS’, for example.

Step 2 – Create a Local Configuration

Each organisation’s directory will require its own distinct git configuration file. The naming of the of the configuration file is also a matter of personal preference, but a convention similar to .gitconfig-xxx has worked best in my experience. Consistency is the key.

The local configuration files should reside at the root directory of each organisation. Each local configuration file should contain the information required to connect to that organisation and a command to select the SSH key to be used:

[user]
email = <email address>
name = <Name for Comments>

[github]
name = "<github user name>"

[core]
sshCommand = "ssh -i ~/.ssh/key name"

The [github] name entry is the user account that has been paired with the SSH key.

The [core] sshcommand is the ssh command that causes the correct SSH keypair to be selected when the Git command line tool is executed.

A configuration file per organisation allows for the correct SSH key to be specified in the configuration file. This allows the correct SSH key pair to be automatically selected without requiring it to be specified on the command line. Now, accessing a repository returns to the simpler:

git@github.com:<user>/<repo>.git

So no more having to remember which key relates to which organisation and repository.

Step 3 – Create the Global Git Configuration

The global configuration file is where the real magic happens. It holds the configuration that enables git to be routed to the correct organisation’s configuration.

A .gitconfig file is created that includes directives, per organisation, to load the specific configuration based on the directory in which the git command is executed:

[includeIf "gitdir:~/code/personal/"]
path = ~/code/personal/.gitconfig-personal

[includeIf "gitdir:~/code/work/"]
path = ~/code/work/.gitconfig-work

[includeIf "gitdir:~/code/company a/"]
path = ~/code/company a/.gitconfig-companya

and so on. The name of the .gitconfig file must match the name you previously specified, and in the directory specified.

Checking the Settings

The settings only take effect when actually in a git repository. Rather than using the HTTPS format for cloning a repository the SSH format will be required:

git clone git@github.com:<user>/<repository>.git

Within the repository, the full configuration can be checked using:

git config --list

Known Hosts

Depending on the ssh setup, the fingerprint of the GitHub host may need to be added to the list of known hosts.

When you run this command:

ssh -T git@github.com

You might get the warning:

authenticity of host 'github.com (x.x.x.x)' can't be established.

There will be an option to continue connecting (yes/no/[fingerprint])? – entering yes will add the fingerprint for the site to the list of known hosts, thus eliminating the error.

Wrapping Up

Whenever I start a new engagement with a client, I get an SSH key pair connected to their source code repository. From there, following the steps described here, I can bring their code in for analysis with a minimum of fuss.

The additional advantage of the directory structure is that when the work has concluded, there’s a single location to clean, making the project wind up similarly less complicated.