8 Easy Steps to Set Up Multiple Git Accounts [cheat sheet included]
Tags: git, devtools, beginners, productivity
Published: 2021-11-02 16:41:13

---
title: 8 Easy Steps to Set Up Multiple Git Accounts [cheat sheet included]
published: true
description: https://res.cloudinary.com/da8kiytlc/image/upload/v1635500807/Cheatsheets/GitGuardian-Git-Accounts-Cheatsheet.pdf
tags: git, devtools, beginners, productivity
cover_image: https://blog.gitguardian.com/content/images/size/w2000/2021/10/21W43-Blog-Git-Accounts-Cheatsheet-Final.png
canonical_url: https://blog.gitguardian.com/8-easy-steps-to-set-up-multiple-git-accounts/
---
>**Disclaimer**: ok, Git "accounts" don't exist - we only have Git configurations. The title is an unorthodox shortcut to talk about accounts hosted by GitHub, Gitlab, BitBucket and such. Not using these? Don't worry, you can still make great use of the this cheat sheet to level up your `.gitconfig` game (look at step n°7).  

## Introduction

Let’s imagine a scenario: you’ve just joined a new company, it’s your first day and you need to set up your new machine. The first thing you do is to rush to get your **own GitHub SSH key** and install it so you can still work on your hobby project. 
A bit later that day, you are finally able to login to your organization repository and you now need to install this key as well to be able to start working.

This is where you realize **it’s essential to know how to manage multiple Git accounts on the same machine safely.**

Want to set up this straight once and for all? We have you covered! 
Take a look at the cheat sheet below! (you can also bookmark or share it)

<a href="https://res.cloudinary.com/da8kiytlc/image/upload/v1647871440/Cheatsheets/GitGuardian_GitHub_Accounts_Cheatsheet.pdf" target="_blank"><img src="https://res.cloudinary.com/da8kiytlc/image/upload/c_scale,w_500/v1647871440/Cheatsheets/GitGuardian_GitHub_Accounts_Cheatsheet.png"></a>
<center><a href="https://res.cloudinary.com/da8kiytlc/image/upload/v1635500807/Cheatsheets/GitGuardian-Git-Accounts-Cheatsheet.pdf" class="call-to-action" target="_blank">Download the Git accounts cheatsheet</a></center>


One key insight from our [State of Secrets Sprawl 2021](https://www.gitguardian.com/state-of-secrets-sprawl-on-github-2021) is that **85%** of all the secrets we catch by live monitoring GitHub are exposed through **developers’ personal repositories**, and a large share of them are in fact **corporate secrets**. 

Multiple hypotheses can explain why this happens. Of course, we cannot discard malicious behaviors, which include corporate resources hijacking and other shady motives. But the sheer scale of the phenomena hints at something else: we are convinced that most of this happens because **error is human and misconfiguring Git is easy**. You think that you are `git push` ing your work with your pro account (by the way, [secrets should **never** enter **any** repo](https://blog.gitguardian.com/secrets-api-management)), while you're actually using your personal one...

Furthermore, any Git repo has a memory that is not easy to rewrite (that’s a feature!). If you want an awesome cheat sheet for rewriting the Git history, [check it out](https://blog.gitguardian.com/rewriting-git-history-cheatsheet/)!

## First things first: SSH or HTTPS?
Most VCS support authentication with SSH or HTTPS: to make things easier, **always prefer using SSH where possible**. 
Git does not cache the user's credentials by default, so with HTTPS, you need to re-enter them each time you perform a clone, push, or pull.
On the other hand, SSH is safer and, when set up correctly (which will be once you follow this guide), you can completely forget about it!

### A quick reminder on how it works
When you hear about an SSH key, most of the time it’s a shortcut to refer to an SSH key pair, composed of a public and a private key, which are cryptographically linked.

The public key, as the name suggests, is openly distributed and shared with all parties. It is used to encrypt messages that can only be decrypted by its private counterpart.

For the connection to be secured, it is essential that the private key remains secret.

The strength of the entire connection lies in the fact that the private key is never revealed, as it is the only component capable of decrypting messages that were encrypted using its own public key.

Note that the SSH protocol uses a mix of asymmetric and symmetric encryption as well as hashing, and the former is not used to encrypt the entire SSH session. Instead, it is only used as a final step to authenticate the client before starting a session. You can learn more about the protocol [here](https://medium.com/@Magical_Mudit/understanding-ssh-workflow-66a0e8d4bf65).

## Step-by-step
Now that you understand the basics of SSH, there is one simple rule to follow: <center><b>one SSH keypair = one Git account</b></center>

The problem is now to manage safely multiple SSH keys and make sure you always use the appropriate one.
Let’s start from the beginning, generating a new key pair for your personal account:

### 1. Generate an SSH key
```shell
ssh-keygen -t ed25519 -C "your_personal_email@example.com" -f ~/.ssh/<personal_key> 
```
ED25519 are recommended for security and performance, but RSA with a sufficient length is also a valid alternative:
```shell
ssh-keygen -t rsa -b 4096 -C "your_personal_email@example.com" -f ~/.ssh/<personal_key> 
```

-C is for adding a comment, it can be anything but it will be helpful to know the email associated with your account
-f is to define a filename, and creating a key with a descriptive name will help you remember which key is used for which user/remote

### 2. Add a passphrase
Next, you will be prompted to add an (optional) passphrase. **We recommend you do so** because it adds an extra layer of security:  if someone gains access to your computer, your keys will be compromised unless they are attached to a passphrase. 

>To update the passphrase for your SSH keys:
>```shell
>ssh-keygen -p -f ~/.ssh/<personnal_key>
>```

You can check your newly created key with:

```shell
ls -la ~/.ssh
```

which should output `<personal_key>` and `<personal_key>.pub`.
By default, ssh searches for filenames of public keys looking like `id_<algorithm>.pub`, but in our case this is not a problem since we are going to specify what keys to use next.


### 3. Tell `ssh-agent`
We will use ssh-agent to securely save your passphrase. Make sure the ssh-agent is running and add your key (the -K option is to store the passphrase in your keychain, macOS only).

```shell
eval "$(ssh-agent -s)" && \
ssh-add -K ~/.ssh/<personal_key> 
```


### 4. Edit your SSH config
If you don’t have one, create an SSH config file 
`touch ~/.ssh/config` and add the following contents to it:

```shell
Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/<created_key>
```

Here we are setting Host to * for every key because we will use **Git configs** to select the appropriate SSH key based on profiles, which will give us a bit more flexibility (more on that later).

### 5. Copy the SSH public key
(<personal_key>.pub) to your VCS of choice ([GitHub](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account), [GitLab](https://docs.gitlab.com/ee/ssh/#add-an-ssh-key-to-your-gitlab-account) or [BitBucket](https://support.atlassian.com/bitbucket-cloud/docs/set-up-an-ssh-key/#Step-3.-Add-the-public-key-to-your-Account-settings) etc...)

macOS
```shell
tr -d '\n' < ~/.ssh/<created_key>.pub | pbcopy
```
Linux
```shell
xclip -sel clip < ~/.ssh/<created_key>.pub
```
Windows
```shell
cat ~/.ssh/<created_key>.pub | clip
```

### 6. Structure your workspace for different profiles
Now, for each key pair (aka profile or account), we will create a .conf file to make sure that your individual repositories have the user settings overridden accordingly.
Let’s suppose your home directory is like that:
```shell
/myhome/
    |__.gitconfig
    |__work/
    |__personal/
```

We are going to create two overriding .gitconfigs for each dir like this:
```shell
/myhome/
|__.gitconfig
|__work/
     |_.gitconfig-work
|__personal/
    |_.gitconfig-pers
```

### 7. Set up your Git configs
```shell
# ~/personal/.gitconfig.pers
 
[user]
email = your_pers_email@example.com
name = Your Name
 
[github]
user = “mynickname”
 
[core]
sshCommand = “ssh -i ~/.ssh/<personal_key>”
```

```shell
# ~/work/.gitconfig.work
 
[user]
email = your_pro_email@google.com
name = Your Name
 
[github]
user = “pro_name”
 
[core]
sshCommand = “ssh -i ~/.ssh/<professional_key>”
```

Here we tell Git which key to use by making explicit the SSH command (the **-i** option is for specifying an identity file or key). This gives us more control, for instance, imagine you have multiple accounts on the same host (like github.com), if you were using the SSH config file to use different SSH keys, you would need to create and remember an arbitrary prefix like first.github.com and then remember to use that domain each time you want to clone a repository with this account. In our opinion, it is less flexible and a bit cumbersome.

This is what you global `.gitconfig` can look like:
```shell
# ~/.gitconfig
 
[includeIf “gitdir:~/personal/”] # include for all .git projects under personnal/ 
path = ~/personal/.gitconfig-pers
 
[includeIf “gitdir:~/work/”]
path = ~/work/.gitconfig-work
 
[core]
excludesfile = ~/.gitignore      # valid everywhere
```

Of course, because many settings will probably be common to the two configurations (like your name or your editor preferences), you can set them here.
 
As a reminder, Git uses **3 overriding levels for configuration**: system, global and local (project). More information [here](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration) on config options.

To see a list of **all config the options**
```shell
man git-config
```
To check your **activated config options**
```shell
git config -list
```

## 8. Repeat for every account/profile
You can repeat these steps for all your VCS accounts and forget about it from now on!

## You're done!
you can now choose to, clone your repo, add or change your remote with:
```shell
git clone git@<repository.domain.com>:<username>/<repo_name>.git
```
```shell
git remote add origin git@<repository.domain.com>:<username>/<repo_name>.git
```
```shell
git remote set-url origin git@<repository.domain.com>:<username>/<repo_name>.git
```

**Pro Tip**: use the `includeIf` statement to setup platform-specific configs
```shell
[includeIf "gitdir:/Users"]
    path = ~/.gitconfig-macos
[includeIf "gitdir:C:"]
    path = ~/.gitconfig-windows
[includeIf "gitdir:/home"]
    path = ~/.gitconfig-linux
```


For [more cheat sheets](https://blog.gitguardian.com/tag/cheat-sheets/), subscribe to the blog below to receive them directly in your mailbox!