# Introducing Gitconfig Provider

Published: 2022-07-02
Updated: 2022-07-02
Canonical: https://prashamhtrivedi.in/gitconfig-provider.html
Tags: Go, CLI, Cobra

---


Everyone is working with Git as their source providers nowadays. Your organization is hosting your code in private Git Servers like Bitbucket, GitLab or Private Git Repos hosted on github. If they work on opensource tools, they may host them in Github. Also you're using a user for your open-source github contributions or some demo or writing a blog like this one.

The account which commits in private work related repos, and account which commits to your opensource github are most likely different users, two different git identities, and switching from one identity to other based on the remote repository is not that straightforward. And most of the times, your commit history will end up like this.

<figure><img src="/twoDifferentIdentities.png"
    alt="Two Different Identities in same commit history"><figcaption>
      <p>Two Different Identities in same commit history</p>
    </figcaption>
</figure>


Like me, if you have faced any issue when switching between personal and work identities in git. I have created a tool that will help us solving the problem, automatically.

## Introducing Gitconfig Provider

To help between switching different git identities, I have created a CLI tool that should run in your git repository. That CLI tool will read your git remotes, apply any config values you add to specific provider before the command runs.

By default this CLI covers 3 git service providers, `Github`, `bitbucket` and `Gitlab`, and on top of that, you can add any provider as long as you have their git remote url handy while adding. Once you add the provider, you can add configs for that provider like `user.email` and `user.name` and any other configuration you like.

Once you are done adding the config, when you run `apply` command, this CLI will fetch your `remote` repository url, finds `origin` repository and apply configuration for that `remote`. If the CLI doesn't find any remotes with `origin`, it will pick the first remote from the list to check for any configs.

If you want to try the CLI, head over to [Releases section](https://github.com/PrashamTrivedi/gitconfig-provider/releases) of the repository and download CLI that runs on your OS.

You can see all available commands from the readme [here](https://github.com/PrashamTrivedi/gitconfig-provider#main-commands-to-note), or you can run `gitconfig-provider --help` command to see all available options.

## Technical Details and some Knowhow.

As I said [earlier](./from-mobile-to-backend-developer.md) I am interested in Go. Prior to writing this CLI, I have prepared some simple CLI helper scripts and I am impressed what Go can do in that space. And that's why I have decided to develop this CLI in Go. 

When I was studying Go with help of [Gophercieses](https://courses.calhoun.io/courses/cor_gophercises), I came to know about [Cobra](https://github.com/spf13/cobra) which adds more functionality over Go's default CLI functionality, e.g. Creating help pages automatically, Creating Subcommands and creating and managing flags properly. So I have decided to use Cobra for managing subcommands and flag.

This CLI works like this. All the configurations and providers are stored in the home directory of user's computer in a `json` file. All the commands are read from or written to the same `json` file, which is managed by a centralized go file called `data.go`.

Whenever a subcommand runs for first time, the file  reads that json file for any existing data stored in the file. If nothing is found, which is the case when this CLI runs for first time in your machine, we will write 3 default providers along with their URLs. You can see all these from this [Code](https://github.dev/PrashamTrivedi/gitconfig-provider/blob/49aec8dc4ad1804b482cb55c60179a468b150454/cmd/data.go#L240)

### The Git Commands and configuration

Everything in Git is done via some commands. Appliying identities is no exception. If we are to do it manually we use `git config {configName} {configValue}` command and that configuration is applied locally to our project. If there is no local configuration applied, git tries to fetch same config from global configuration file and applies it to your repository. You can add global configuration using `--global` flag in git config command. Thus `git config --global {configName} {configValue}` will apply same config Globally for your machine.

Every commit must have `user.name` and `user.email` property attached to it. Without that git won't let you commit anything. Ideally this is stored globally in your machines, or this is stored locally using command line or in `.gitconfig` file.

Usually to have different identities, you should run `gitconfig-provider addConfig -provider={ProviderName} -key=user.name -value={YourProviderUserName}`.

For Example in github you should fire below commands to add your identity for github.

`gitconfig-provider addConfig -provider=Github -key=user.name -value={YourGithubUserName}`

And

`gitconfig-provider addConfig -provider=Github -key=user.email -value={EmailYouUseForGithubCommits}`.

To confirm this setup, when you run `gitconfig-provider listProviders` you can see your github user name and email loaded with the value you have provided with abive commands.

## Releasing the Binaries using GoReleaser

I like the way that all the output of Go is standalone executable binaries that can run directly in a host machine without any external runtime or library installed. GoReleaser is a tool that automates and simplifies lot of your deployment processes, especially when we are doing some OS Specific stuffs like running commands in Shell/Bash (in Unix like systems) of Cmd in windows. ([Like this](https://github.dev/PrashamTrivedi/gitconfig-provider/blob/873aaca6bb69e4243894ecc4b644a15d86a08c79/cmd/data.go#L72-L82)). 

By default when we run `go build` command, Go will create binaries for OS and architecture in machine the command is run. E.g. If you're running in 64bit Linux machine, `go build` will create a binary that can run on 64 bit Linux machine, not for windows or Mac. If you want to create a binary for all the OS and Architectures, you need to pass necessary flags while creating binaries. Like `GOOS=windows GOARCH=386 go build -o ...` or `GOOS=darwin GOARCH=amd64 go build -o ...` to build for Windows x86 machines or 64bit mac machines. Doing this manually is tedious process. And GoReleaser makes this and other tasks far more easier.

GoReleaser reads a configuration file called [`.goreleaser.yml`](https://github.dev/PrashamTrivedi/gitconfig-provider/blob/67a08dc709f234a71c6edad9c537f1aeb5de8fa7/.goreleaser.yml). We can use this configuration file to list out all the OS and Architecture, apart from that we can configure any commands to run as build hooks, or how to manage the output and changelog. GoReleaser also provides [Github Action](https://github.dev/PrashamTrivedi/gitconfig-provider/blob/49c0488210eb60b57ae23ba141727d70a44c405c/.github/workflows/release.yml) that will create a Github Release everytime we push any tags. You can read more about GoReleaser [here](https://goreleaser.com/).

You can download latest `gitconfig-provider` releases from [here](https://github.com/PrashamTrivedi/gitconfig-provider/releases). Play with it and let me know what you think about this CLI. If you find any issues, feel free to create an issue [here](https://github.com/PrashamTrivedi/gitconfig-provider/issues) or feel free to add any discussions [here](https://github.com/PrashamTrivedi/gitconfig-provider/discussions).

## Future

This is not it for gitconfig-provider. The CLI lacks cloud storage where users can backup their settings centrally from any machine and can restore it to any machine. The codebase also requires some refactoring and testing needs to be added before that. I will write posts about them when their time comes, till then.

*May the force be with you...*