[xp84]

This is pretty cool.

I'm curious, what are people's opinions about the pro/cons of maintaining multiple GitHub identities like this?

Personally, I have never found it necessary to do this, but about 1/3 to ½ of the people I work with usually have "-companyname" in their usernames, so it appears semi-popular.

What I do is just add my work email as a secondary to my GitHub account and configure the work laptop to use that email, and I generate a new RSA key and add it to my one account. Then I also set up the notifications to use that work email as the notification email for things in that organization

My "Pros" list for doing it this way:

* Simple to configure my git/ssh settings - just add the SSH key on my work laptop to my normal GitHub account

* Easy for someone to identify and even reach me if they were to see a commit in GitHub. For instance, if they know I wrote something they might want to hire me again later to update it.

* I "Sign in with GitHub" to things like developer tools (like Codesandbox, for instance), I get to easily keep control of that account even when I change jobs.

"Cons" I can think of:

* Technically a malicious actor in (or who has compromised) corporate IT could impersonate me by stealing my key from my work-owned computer, cloning my private Github repos, and could introduce changes into other repos I have access to. So I assume if I had high-level access to important OSS projects, this would be a danger for targeted hacking. (Obviously since I can remove the keys at the end of an engagement, I can at least limit my exposure to just current clients/employers.)

Is there anything else that makes you prefer to use a company-specific identity?

[thekombustor]

Keeping work/private life separate is reason enough to me (also, we don't use Github - we use bitbucket - the decision was made for me!)

Ultimately, I think having work-specific accounts is preferable, and I wouldn't be surprised if a lot of IT departments also prefer this (however, this is also coming from the medical space, where controls are rather tight and security is extremely important and heavily audited)

[pc86]

I've worked for a handful of medical companies, including ones that handle de-anonymized PHI/patient data and/or develop medical devices, both very heavily audited and regulated even in comparison to other medical companies. Using a personal GitHub account attached to an organization on either GitHub proper or GitHub Enterprise was never an issue. Sure we had some folks create a separate account because they wanted to, but there no directive from the IT/security folks even suggesting that, and I'd consider them showing any preference toward not just attaching your personal account a big organization red flag - it means they're just defaulting to "don't do that" rather than actually taking five minutes to understand the constraints and ramifications.

[computerfriend]

That con was reason enough for me to never do this. Another reason is, when using my personal GitHub account, I'm doing personal things and don't want to see work-related stuff (even if it is just private contributions or the "use SSO to see $employer repositories" message).

[Arnavion]

The company can mandate SSO, security settings, profile settings like avatar or description, etc that you don't want to apply to your personal account.

Also, once you leave that company, you don't have to worry about unsubscribing from that company's repos, issue threads, etc, or worry about people still @-mentioning you because you participated in those repos before.

[jackbravo]

about the "cons", another con is that granting access to your unified account from your work or business perspective is "tricky". Github Business accounts can grant specific access only for people identifying with your company's identity provider, like okta or similar. So that can potentially reduce that risk as well, so that your employer can revoke access to okta, and thus revoke access to work repositories, for example. Without that you need to be very strict and do some manual work to grant and revoke accesses.