DevOps - Git Multi-Account Management

  • Git
  • Windows

 

 

Git has become the default control version tool for the significant majority of developers. It is easy to setup and configure as the only required commands from git are:

 

$ git config --global user.name "John Doe"

$ git config --global user.email johndoe@example.com

 

 

If you are using gitbash on Windows or working on a Unix system, you might need to add your ssh keys to be able to work with your remote repositories through ssh:

 

$ eval "$(ssh-agent -s)"

$ ssh-add ~/.ssh/id_rsa

 

These steps are very well documented on the web, and this is where the configuration will usually end. But it can get a little tricky when you work at NearShore internal projects, have a couple of different clients, or just work with your personal GitHub repository on the same computer. Most people won’t notice anything weird in the following picture taken from a commit I did at the Nearshore Gitlab repository:

 

 

Most people will say, that my commit was successful and that I just broke some pipeline with my changes. But most people will need to look at the small details. Here is some help, we need to zoom in the bottom left corner:

 

 

As I mentioned, this commit I did a year ago was done for a NearShore internal project, but the email tied to that commit is the one I use for one of our customers, BD. When I noticed this, I also realized that all my commits tied to this email were not showing the profile image I had selected for my account. Investigating my git configuration, I noticed that my git was attaching the first email I used when running “git config --global user.email” command.

 

I came to understand that there was a configuration conflict when using more than one email account, as when you have to work on different projects. The quick workaround for this is to use:

 

$ git config user.name "Your project specific name"
$ git config user.email "your@project-specific-email.com"

 

This should be applied to every repository you clone, so that when you push your changes it has the proper email address. But, what happens when you work on 4 or 5 repositories per account? Do we need to set up our email and user name for every project we clone? Is there a better way? Yes, there is!

 

We need to edit our “.gitconfig file”. My file was on this path

“C:\Users\jose.mayoral\.gitconfig”

 

And it will show something like this:

 

 

 

Here we can see my global configuration. We need to look for a way to make git select the proper configuration for the account currently in use (NearShore or BD). The solution is to use the “includeIf” section. This section allows us to include a configuration file that will merge with the global configuration file if some specific conditions are met. There are many ways to configure this section, as I was using a different folder to separate my repositories of NearShore and BD, I decided to use the “gitdir” keyword to select the proper configuration. So if my NearShore folder was called “nearshore_dev” and my BD folder was “GitDevOps”. I just needed to modify my “.gitconfig” file by removing the email from the global context and adding the “includeIf” sections at the end of my file:

 

 

 

 

So if git detects that the root directory of my repositories is “nearshore_dev”, it will merge the global config file with “.gitconfig-nearshore”. If the directory is “GitDevOps”, it will use the “.gitconfig-bd” file for the merging. The file “nearshore_dev” contains:

 

 

 

And the “.gitconfig-bd” file has:

 

 

 

This will allow git to select the correct email whenever I push to the remote repositories. After doing these changes, my commits to the NearShore internal projects look like this:

 

 

 

Caused by GitLab recognizing the email attached to the commit.

 

Probably I could have overlooked the wrong email detail in the commit forever, but small details like these can make the difference when a new developer is looking at the commit history; he might wonder if there is some external contractor that uses an external email. Keeping the git history clean and clear is vital to deciphering the history of our projects. Our responsibility is to make the best use of the tools we have at our disposal.

 

Any questions you can always ask: jose.mayoral@nearshoretechnology.com