[HN Gopher] Gitas - A tool for Git account switching
       ___________________________________________________________________
        
       Gitas - A tool for Git account switching
        
       Author : letmutex
       Score  : 54 points
       Date   : 2026-02-17 08:51 UTC (4 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | rgoulter wrote:
       | For the use case of "use different accounts / configs for
       | different directories", git's config has includeIf.
        
       | 7777777phil wrote:
       | Lovley, was looking for exactly that for some time. Will
       | definitely try it, thanks for sharing!
        
       | Kwpolska wrote:
       | Solving the problem of having a personal and a work GitHub
       | account is really trivial without any extra tools. All you need
       | is a dedicated SSH key for that GitHub account. (And why would
       | you have a password for a ssh key on your personal machine?)
       | 
       | ~/.ssh/config                   Host github.com-work
       | HostName github.com          User git          IdentityFile
       | ~/.ssh/work_id_rsa          IdentitiesOnly yes
       | 
       | ~/.git/config                   [user]         email =
       | work@example.com              [remote "origin"]         url =
       | github.com-work:Work/Widget.git
        
         | embedding-shape wrote:
         | Which works for a while, until you have a bunch of projects
         | under various identities.
         | 
         | In my main ~/.gitconfig I have:                 [includeIf
         | "gitdir:/home/user/projects/embedding-shapes/"]       path =
         | /home/user/.gitconfig-embedding-shapes
         | 
         | Where basically `projects/` follow GitHub naming with
         | $user/$repo, so I set the git identity based on all projects
         | within that user, rather than repo-by-repo which would get
         | cumbersome fast.
         | 
         | Then you just make sure you're in the right directory :)
        
           | accoil wrote:
           | I use that approach. I also make sure to not set the [user]
           | section in my main config (and only in the included files).
           | That way if I'm operating outside of one of my user
           | directories git commit fails due to having no user details.
        
           | beaker52 wrote:
           | This. I've seen so many tools solving problems that already
           | have solutions lately because LLMs allow people to run off
           | and "fix" the problem their way before they can a chance to
           | discover existing, more appropriate solutions.
           | 
           | The next step of this problem space is: "when I'm working on
           | project X, I often forget to change my GitHub user with
           | Gitas" so now they need direnv or something to switch it for
           | them. The original solution foresaw this - so is far more
           | complete that Gitas already _and_ built into git itself.
           | 
           | But, LLMs, so here we are, slowly drowning in a growing ocean
           | of software built by the unaware.
        
             | Terretta wrote:
             | > _built by the unaware_
             | 
             | awash in bliss
        
         | arccy wrote:
         | If you don't want to bother with directories or want to use
         | https instead of ssh, you can do remote url based dispatch in
         | your gitconfig:                   [credential
         | "https://github.com/org1"]           useHttpPath = true
         | helper =           helper = /path/to/auth.sh user1
         | [includeIf "hasconfig:remote.*.url:https//github.com/org1/**"]
         | path = user1.gitconfig           ; set name / email in
         | user1.gitconfig
         | 
         | where auth.sh is something that can produce the right token for
         | the given user, e.g.                   #!/bin/bash         echo
         | "username=$1"         echo "password=$(gh auth token --user
         | $1)"
        
         | xn wrote:
         | Are there any good reasons to use multiple GitHub user
         | accounts? GitHub organization membership and permissions are
         | well designed in my experience, negating the need for multiple
         | user accounts.
        
           | embedding-shape wrote:
           | > Are there any good reasons to use multiple GitHub user
           | accounts?
           | 
           | Is there any good reasons not to separate what you work on
           | into multiple GitHub accounts? Not to mention some people
           | don't want all their projects attached to one profile, some
           | people also develop in their free-time, and don't want to mix
           | freetime/work projects under the same user account, for
           | multiple reasons.
        
           | jimmydoe wrote:
           | A why not
           | 
           | B if you ever be in a company using the half baked GitHub
           | hosted enterprise....
        
           | StarlaAtNight wrote:
           | Consultants or professional services folks will be working in
           | their company's GitHub account and several clients. Requires
           | managing lots of git/GitHub accounts
        
             | Terretta wrote:
             | Simplifying for brevity* -- there are three levels in the
             | GitHub entity:                 - accounts (personal)
             | - orgs (companies, directories, teams, roles etc.)       -
             | enterprises (sets of orgs)
             | 
             | Even with enterprise SSO, the initial connect to GH can (is
             | typically) "you" (just as you have the same driver license
             | to show at the front desk when registering to visit a
             | secured firm or random hotel), then you elevate "you" into
             | the org through SSO, and what policies apply to you via
             | your org can be 'governed' at the enterprise.
             | 
             | The idea behind this model is that no, you don't have to
             | manage lots of those as you, you're just you, and each of
             | those you aim to use has an elevation that entity controls
             | instead of you controlling it.
             | 
             | This ultimately results in way less key material floating
             | around, and you losing, leaking, or lousing up your own GH
             | cred doesn't auto-give an attacker the SSO elevation.
             | 
             | * * *
             | 
             | Not incidentally, I have a slew of "accounts" given to me
             | by companies that don't bother to make an org, they just
             | invite individuals to repos or make individual accounts for
             | their repo. I suppose it's cheaper in the short run. In the
             | long run, these accounts are 90% still left active years to
             | (no kidding) decade+ later. Seems a better idea to "don't
             | do this." If you're a company, be an org.
             | 
             | ---
             | 
             | * _Expanded for more depth:_
             | https://docs.github.com/en/get-started/learning-about-
             | github...
        
           | Hamuko wrote:
           | I use a pseudonym during my free time, so yes. Also my
           | employer is requiring us to use company-specific GitHub
           | accounts, so the decision is out of my hands anyway.
        
         | jimmydoe wrote:
         | For Claude Code users:
         | 
         | - using alternative host is not supported when roaming between
         | local and cloud, fix is to add another origin you don't use but
         | use GitHub.com url
         | 
         | - CC uses gh command, which still needs account switch, this
         | can be solved by add the switch to CC hook.
        
         | adithyassekhar wrote:
         | Is this that dropbox moment again? Anyway on Windows I keep a
         | separate work and personal profile and GitHub auth doesn't go
         | between them.
        
         | OrderlyTiamat wrote:
         | > (And why would you have a password for a ssh key on your
         | personal machine?)
         | 
         | You're presumably joking? If not, could you elaborate?
        
           | PunchyHamster wrote:
           | well if you have encrypted storage and already need password
           | to get to it, secondary password is of little value
           | 
           | Tho I prefer to just use hardware key for ssh
        
             | rzzzt wrote:
             | ssh-agent will also be happy to provide the key to git
             | after an initial unlock with the passphrase.
        
             | craftkiller wrote:
             | > well if you have encrypted storage and already need
             | password to get to it, secondary password is of little
             | value
             | 
             | That's only true when your machine is powered off. If an
             | attacker manages to yank files from your disk while it is
             | running, that ssh-key password is the difference between
             | "they stole my ssh key" and "they stole worthless random
             | data".
             | 
             | > use hardware key for ssh
             | 
             | That's the real solution. I don't understand why people
             | still store ssh keys on disk when hardware keys are simple,
             | easy, and significantly more secure.
        
               | bubblewand wrote:
               | > That's the real solution. I don't understand why people
               | still store ssh keys on disk when hardware keys are
               | simple, easy, and significantly more secure.
               | 
               | At work, every place big enough to maybe care about this
               | was so "enterprisey" and "cloudy" that I almost never
               | use/used ssh anyway, even with tons of Linux systems all
               | over the place. Pretty much only to talk to GitHub.
               | 
               | I lose stuff all the time. The idea of these things gives
               | me anxiety. The first time I lost 15 minutes figuring out
               | where I put my hardware key, before I could ssh in to do
               | 20 seconds of running commands, I'd back out of the whole
               | project and return to using a file on disk, guaranteed.
               | 
               | Files on disk are free, hardware keys cost money.
               | 
               | 25 years as a backend-heavy programmer, sysadmin, and
               | devops-sort (sometimes all at once, lol). I've still
               | never even touched one of these devices, and have only
               | rarely seen one.
        
             | fastasucan wrote:
             | >well if you have encrypted storage and already need
             | password to get to it, secondary password is of little
             | value
             | 
             | This is not true at all though. What about when you are
             | logged into your computer.
        
         | hrpnk wrote:
         | The host shenanigans are simpler addressed with `git config
         | core.sshCommand` which overrides the default key and selects
         | the desired one on a per repository level.
         | 
         | source: https://erik.doernenburg.com/2017/12/using-multiple-
         | github-a...
        
           | CamJN wrote:
           | Doesn't work for cloning, obviously. The way I handle it is I
           | have ssh look at the hostname and path passed by git and
           | decide which identity to use. This is very easy in openssh
           | 10.0+ using the command matching syntax, and more difficult
           | to varying degrees on earlier versions of openssh, depending
           | on your OS.
        
       | dvratil wrote:
       | I used to have a git post-checkout hook that set the repo
       | identity based on the repo origin url [0] on checkout - maybe
       | there's some post-clone hook these days, but 10 years ago when I
       | wrote it there was only post-checkout hook.
       | 
       | [0] https://www.dvratil.cz/2015/12/git-
       | trick-%23628-automaticall...
        
       | eqvinox wrote:
       | You can put [user] blocks in repos, i.e.
       | /some/where $ head .git/config       [user]        email =
       | me@example.org        name = My 'nick' Name
       | 
       | Doesn't tie into your SSH key though, if you need that.
        
         | turbocon wrote:
         | You can manage multiple ssh keys via your ssh config too. But
         | this does seem to make things easier, I always end up fighting
         | with this when I need to do it once every 3 years
        
       | sevensor wrote:
       | Git _hub_ account switching. A git account is not an idea that
       | makes sense.
        
         | embedding-shape wrote:
         | It's actually about _git_ account switching as far as I can
         | tell, which does make sense, you can have multiple  "git" users
         | indeed. Maybe it's the wording that is wrong? Read "account" as
         | "user" and it might make more sense :)                 # in
         | ~/.gitconfig       [includeIf
         | "gitdir:/home/user/projects/embedding-shapes/"]         path =
         | /home/user/.gitconfig-embedding-shapes            # in
         | ~/.gitconfig-embedding-shapes       [user]       name =
         | embedding-shapes       email = embedding-shapes@proton.me
         | [core]       sshCommand = ssh -i /home/user/.ssh/id_embedding-
         | shapes
         | 
         | That's one of my git "accounts", currently I have four in
         | total, one being my "real identity", other are pseudo-anonymous
         | users.
        
           | sevensor wrote:
           | Fair point. This makes much more sense when you make it about
           | your git identity + ssh configuration.
        
         | christoph-heiss wrote:
         | Yeah. Unfortunately, just goes to show how many people think
         | Git = Github.
        
       | aditya24raj wrote:
       | GitHub CLI has a command - gh auth switch. It makes it really
       | easy to switch between GitHub accounts. I also wrote a small
       | blog/guide about it- https://aditya24raj.github.io/blogd/using-
       | multiple-github-ac...
        
       | PunchyHamster wrote:
       | you can have per repo and per directory git config via git
       | conditional includes                   [includeIf
       | "hasconfig:remote.*.url:https://*.github.com/**"]         path =
       | /home/xani/src/gh/.gitconfig
        
         | silverwind wrote:
         | Quite nice. I had to split into two statements to make it work
         | for both https and ssh because of a bug in git:
         | [includeIf "hasconfig:remote.*.url:git@git.work:*/**"]
         | path = ~/.gitconfig.work         [includeIf
         | "hasconfig:remote.*.url:https://git.work/**"]           path =
         | ~/.gitconfig.work
        
       | sigmonsays wrote:
       | Feel free to have your own workflow but git already addresses
       | this tools entire purpose with includeIf.
       | 
       | what does this address that includeIf does not?
        
       | teeray wrote:
       | When did using a single per-machine SSH key on a Yubikey become
       | so dirty in the eyes of these enterprises?
        
         | csullivannet wrote:
         | For me it's mostly just that the SSH performance on a large
         | monorepo is much worse than HTTPS.
        
       | nsonha wrote:
       | what does this do more than gh switch? I would rather something
       | that automatically picks the right user based on the org
        
       | lasgawe wrote:
       | This is nice! This was a problem I faced a few years ago at my
       | job. What I did was create a custom Bash function to switch Git
       | accounts and add it to my .bashrc file. I love this. I'll give it
       | a try.
        
       | djoldman wrote:
       | For the folks looking at tools to help manage personal and work
       | identities on the same computer: don't.
       | 
       | Never access personal accounts from a work computer or work
       | accounts from a personal computer under any circumstances.
       | 
       | This goes for laptops, desktops, and especially cellphones.
       | 
       | If an employer asks that you violate the above, ask for a
       | dedicated device owned by your employer to access a work account.
       | If they refuse, that's a big red flag. "Oh just use your phone to
       | check your email/slack" - 1. don't assume everyone has a
       | cellphone and 2. if you want folks doing work on a device, pay
       | for it.
       | 
       | Managing multiple personal accounts on computer A or multiple
       | work accounts on computer B is totally fine.
       | 
       | As an aside, company general counsels might be shocked at how
       | often their employees log in to slack/email/etc. from their
       | personal cellphone: suddenly any and all company and customer
       | intellectual property has a way to leave the network. And it's
       | not even a "pull" from the employee as the other employees just
       | "push" them messages.
        
         | Groxx wrote:
         | In some states, employers are _required_ to provide this as an
         | option, at least for some devices:
         | https://www.driversnote.com/blog/state-requirements-cell-pho...
         | 
         | Obviously it should be everywhere, for all tools needed to do
         | your job, but it's especially clear for tech where nearly all
         | large companies will also exert control over the device.
        
       ___________________________________________________________________
       (page generated 2026-02-21 23:02 UTC)