How I configure my Git identities

I used to work at a startup with a character who would set his identity to be random fairytale-sounding nonsense, changing every day. So his commits on Monday would be attributed to Mr. Bunnymann, and Thursday would be Doctor Funtime, etc.

It was super unhelpful when trying to do version control forensics. But if I'm being generous, I think maybe he was trying to remind everyone that anyone can put anything in their identity config, and we shouldn't trust whatever is in there for all that much.

One even-better approach IMHO

Just keep a .gitconfig in your HOME with aliases for your identities. Then just after initializing/cloning the repo do git config-company or git config-personal

    er453r@r7:~$ cat ~/.gitconfig 
    [user]
        useConfigOnly = true
    [alias]
        config-personal = !echo CONFIG-PERSONAL && \
            git config --local user.email 'personal@email.com' && \
            git config --local user.name 'personal' && \
            git config --local core.sshCommand 'ssh -i ~/.ssh/id_rsa_personal'
        config-company = !echo OLD CONFIG-COMPANY && \
            git config --local user.email 'official@comapny.io' && \
            git config --local user.name 'Name Surname' && \
            git config --local core.sshCommand 'ssh -i ~/.ssh/id_rsa_company'

I do something similar, but instead of `insteadOf`, I just clone the repo with `gh-work:org/repo`, and in the git config:

    [includeIf "hasconfig:remote.*.url:gh-work:**/**"]
        path = ~/.gitconfig.d/gh-work.inc

So, any git repo cloned with the ssh identity defined under `gh-work` will take on the config of `gh-work.inc`, which includes the git identity, and also the same signing key as in the ssh config.

Essentially, the name `gh-work` becomes the distinguishing element in both my ssh identity and my git identity, and I find this easier to think about.

I always strongly advise consultants to use a separate machine for work, or at the very least a separate OS user.

You’re risking putting yourself in a whole lot of trouble by using a personal machine for work.

you don't have to mess with ~/.ssh/config

Just put this in your ~/.gitconfig (or ~/.config/git/personal as in the article)

  [core]
      sshCommand = /usr/bin/ssh -o IdentitiesOnly=yes -i ~/.ssh/IdentityFile2 -a

This makes submodules easy without the `insteadOf`

And if you have more than one SSH identity?

You can also put that in your includeIf confs. I updated the parent comment

Sounds like a different problem.

[dead]

Thank you for this! I have exactly the same problem and was waiting for the solution to present itself, which it now has.

Aside: I use NixOS with home-manager (on linux and mac), which makes this trivial [1]. Added the following lines to my home-manager config:

  programs.git = {
    enable = true;
    ...
    includes = [
      {
        condition = "hasconfig:remote.*.url:git@github.com:<work>/**";
        contents = {
          user.email = "<work email>";
        };
      }
    ];
  }

[1]: https://nix-community.github.io/home-manager/options.xhtml#o...

That certainly looks less trivial than writing it directly in your .gitconfig file. It's the same condition and setting as what's in the article, but now with a build/templating stage and a new programming language to learn with unusual syntax.

I've been using `includeIf` with directory for ages (https://www.bobek.cz/til/git-identities/), the `hasconfig:remote` is really neat. And it also works when cloning the repository.

> Note: I've had this post drafted for 3 YEARS!!! It's finally time to publish it.

Did you say that just so we could imagine the world where you published it earlier?

Thanks anyway, and nice site!

I've written a short blogpost about how to link SSH Keys to Git identities: https://brainfood.xyz/post/20241030-use-a-specific-ssh-key-i...

The includeIf stuff is pretty neat. I currently keep the SSH complexity in ~/.ssh, where I have several includes, one for each customer|project|identity. Things without unique hostnames, like github, get an alias assigned:

    Host customer-github
     Hostname github.com
     IdentityFile ~/.ssh/customer_rsa
     User git

All I have to do is use the alias in any git clone command and I'm done.

I have created a tool 12 years ago (still actively maintained) to manage multiple GitHub SSH identities:

https://github.com/dolmen/github-keygen

So glad I clicked on this link. I was already doing the `includeIf: "gitdir"` thing to separate work and personal stuff, but `hasconfig:remote` is a total game-changer.

absoluelty! I can't believe this treasure was hidden as a draft for three years!

This is a nice trick. But if you:

* use a dedicated work machine and

* also want to version control your dotfiles (including ~/.config/git/) and

* don't want to leak your work repository organisation via your dotfiles,

you can instead add something like

    [include]
        path = work.gitconfig

which will override any settings above it and also fail gracefully/silently if work.gitconfig does not exist.

Shameless plug for a tool I developed in order to easily switch git identities based on projects: https://github.com/cquintana92/git-switch-user

After configuring the identities you just need to run

    $ git su Personal
    $ git su Work

And all the identity configuration (email, name, SSH key and optionally PGP key) will be set up into the repo's .git/config file.

Saved me a ton of time.

Shameless plug for a tool I developed in order to easily manage GitHub identities for Git access via SSH:

https://github.com/dolmen/github-keygen

12 years old, but still actively maintained.

I love that Rek drew the image on your about page. I knew I recognized their work as soon as I saw it.

Based on that and your 1.44MB Club, you might find Neat CSS interesting. :P

https://neat.joeldare.com

My Neat CSS websites will almost always fit on a floppy and I have a case of old floppies right here in my closet. The Neat CSS home page is only about 12k. Things get bigger when you start adding images, of course.

[deleted]

> Note: I've had this post drafted for 3 YEARS!!! It's finally time to publish it.

I suddenly felt a deep connection with the author. It is not only me.

I promise you, my dear drafts, that one day, I will set you free to see the world!

Is there a risk with not using different keys for work and personal?

The private bits are all in the same place: if one is compromised, so are the rest.

There is also a risk using the same machine for work and personal. I’d address that first.

About signing keys, it would make sense stopping using a signing key (marking it as such and deleting it) once you stop a job.

Your signing key for personal projects probably has a different temporality.

> About signing keys, it would make sense stopping using a signing key (marking it as such and deleting it) once you stop a job.

What does this achieve exactly?

Your key cannot be tied to more than one identity, and if you use GitHub Enterprise, your work identity may be restricted from contributing to repos outside of the Enterprise. This is to prevent cloning private code into public spaces. For this reason, you need to have separate keys.

Interesting!

Curious though that the compliance rules are strict enough it warrants distinct keypairs, but not that strict for the devs to use dedicated hardware.

If both of your keys are on the same computer they would most likely be compromised simultaneously, or not at all.

However if you're worried about this then you should probably be using a hardware token anyway - something that supports SSH authentication via FIDO2, GPG, or smart card interface.

I hated configuring multiple Hosts/aliases in my ~/.ssh/config for Github/Bitbucket when dealing with different keys for different clients.

I ended up creating a "SSH environment" manager 4 years ago to help with this: https://github.com/theonejb/sshenv

It's worked wonderfully for me since then, and it's something I use almost daily.

I use `insteadOf` instead of ssh alias because my workplace use GitLab orgs. So instead of typing the full URL like:

  git clone gitlab.com/acme-corp/project-name

I could use:

  git clone work:project-name

But this kinda broke `includeIf` since it store the `insteadOf` remote url directly. I then had to convert existing repositories to use the `insteadOf` url.

I wrote a little bit about it here: https://bentinata.com/log/git-insteadof-includeif

This post is a great reference of what’s possible with git config wrt includes/remotes, and I’m sure I’ll be getting back to it.

One thing though: what’s the point of using separate keys for work/personal/github/gitlab? I fail to see a practical and security advantage over using one key (per workstation).

To add to my other replies to replies in this thread…

These days I prefer to use local VMs to compartmentalize different areas of work (personal, consulting, etc) so my git config is plain and simple. Lately I’ve been doing mostly consulting work around open-source so I’ve been using my primary GH account for the most part, but separate VMs allow me to use a different key (account) without advanced git config incantations.

Privacy for sure. It's no ones business to know how certain accounts are related.

Ah, right. E.g. using separate GH accounts for personal and work. Forgot about that!

GitHub does not allow you to share a key with another GitHub account anymore

Of course! I’ve been using separate GH accounts for work and personal stuff in the past myself. It’s been years since then and I completely forgot.

In fact, I was one of not too many who used separate account for work, and people didn’t understand it, wondering why the hassle.

They never did. The account is identified by the key, so it's impossible.

Why have multiple git identities in the same machine? I use a single different key with each machine and that's it.

I use a unique account with every distinct git org / github org that I interact with.

Even if I'm in my work profile and I need to do something in an org called `acmecorp`, I will create @acmecorp-identifier to do that.

This is just a very long experience...

* Security policies for work things have a blast radius of just that employer

* OSS things have a lifetime beyond the life of an employment / contract

* Source control elsewhere (GitHub / GitLab / Bitbucket / Gitea / Forgejo / etc) all has a local blast radius, and if a provider / org forces changes (roll your keys!) then the impact is limited to just that provider

* When something changes ownership (i.e. an org), the impact to me is low

It seems much more sane.

I think of a single git identity across multiple orgs as a bit of a smell.

I use different accounts for my work GitHub and my personal GitHub, so this approach would be great if I shared a machine for both of them to keep separation.

As cool as this is, how many peoples' employers allow them to do either personal work from the work computers, or work work from their personal computers? My company is quite strict on both.

I've not had a single employer care.

For many of the companies that I've worked at, the laptops were taken home to be used as personal computers at the end of the day and this was a well-known thing and I was often looked at weird when I said I had another laptop.

One time I took the wrong laptop in and had to work on my personal laptop in the office. It wasn't so much fun that day.

I really liked the website, the layout, typography, icons etc. Really well done!

Especially the TLD

The whole domain name for me, my childhood dog was named Benji :)

... time to go change my security questions

user.useconfigonly=true can also help