Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've moved all our company Git repositories to GitHub and now I want to add employees to the projects. Since most employees already have personal GitHub accounts, I'm wondering whether I should ask them to create a work GitHub account. The reason that I'm thinking of doing this is to decrease the chances of unauthorized access to our code base since their personal accounts may be well publicized through their personal activity on the site, increasing chances of targeted attacks. Furthermore, if their personal account is ever compromised it won't mean the whole company code is accessible to the hijacker. Since this will bring the burden of maintaining two accounts for the employees I'm wondering whether it is the correct approach and whether it even makes sense. I would love to hear your opinions on this.

Update Thanks for all the useful insights. I won't set an answer as accepted because of the subjective nature of the question/answers and since I took the best points from several different answers.

I have decided to go forward this way: I will remind employees that work-related GitHub e-mail notifications will have to be sent to their work e-mail accounts for practical reasons. Therefore it would make more sense to create work GitHub accounts. If they are willing to use their personal GitHub accounts and connect it to their work e-mail accounts then that's fine. In any case, employees will have to agree in written form to a number of conditions tied to using GitHub. These are related to account security: choosing a secure password using a secure random password generator that is not used with any other account, not accessing GitHub through computers not owned or administered by them, etc. At the end of the day employees will have to decide themselves whether a work account makes more sense for them or not.

share|improve this question
The work account would be equally easy to compromise, wouldn't it? –  Boris Yankov Jun 5 '12 at 22:18
GitHub added per-organization email routing in August, 2012. github.com/blog/1204-notifications-stars –  Paul Schreiber Feb 1 '13 at 14:18
@BorisYankov the work account may be harder to compromise, if you don't have any public activity and the login has no relation with your name. It's security by obscurity, but it for sure helps. You can create a workflow that all emails sent by github are as well sent to the development team leader, etc. Another point: As work account you can decide and even do due diligence, auditing accounts and see if they are compliance with what was agreed between company and employee. A third important point: as soon as the user quit his job, you can take over his account. –  VP. May 21 '13 at 20:33
add comment

9 Answers

I'd be insanely leery about putting my company's intellectual property on someone else's servers, no matter who it is.

Is GitHub Enterprise out of the question for your company? AFAIK, it deals with all of these types of potential security risks out of the box.

share|improve this answer
I've seen GitHub Enterprise but find it too expensive (we're a startup). We thought a lot about using GitHub. But after weighing to pros and cons we decided to do it anyway. –  fiorenti Jun 4 '12 at 17:31
What about BitBucket? It has free private git hosting. –  Florents Tselai Jun 4 '12 at 20:40
@Florenc: if putting your IP on someone else's server is risky, doing it without paying them is often much more risky. –  user4051 Jun 4 '12 at 20:53
GitHub Enterprise is absurdly expensive. GitLab is free. Depending on your type of business I don't see a problem with using GitHub hosted paid accounts. –  Andrew Finnell Jun 4 '12 at 22:57
@Demian Brecht Being leery is a good thing, but at the same time do you not think that GitHub, whose business is focused on hosting, would pay better mind to security than a few guys with more than just a VCS on their mind? –  Glenn Nelson Jun 5 '12 at 0:41
show 6 more comments

If there was a benefit, it would merely be painful. But nothing sucks worse than painful and pointless. Just have the single personal account. Two reasons:

  • Github has incredibly good access control in their organizations. If an employee leaves, you can instantly remove their access. If they had a company account, you'd have to reclaim the account somehow to get the stated benefits. In practice, you'd probably just remove the account access, same as if they had a personal account.

  • Having more than one account is painful. Logging in and logging out between accounts hurts, and adding comments, following, and all the social stuff when you use different accounts.

References: I make a CI server that has GitHub integration, so I have about a lot of test accounts, and I've talked to customers with all sorts of weird configurations, including separate work accounts and personal accounts. It always leads to trouble.

share|improve this answer
add comment

Is your company's code in public or private repositories? If they (or at least some) are public, and you allowed your employees to use their own GitHub accounts, then it would be an incentive for them to write good code. Their name would literally be attached to it, publicly. However, I'll assume that all of your repositories are private.

Overall, it sounds like you would prefer that your employee's accounts to not be publicly visible throughout GitHub. Unfortunately, they make money by selling GitHub Enterprise so I imagine that's one reason why they don't allow you to create private accounts for organizations. In either case, having (essentially) locked-down work accounts would be really counter-intuitive after choosing a very social site to host your repositories.

Lets imagine that you did set up work accounts for your employees. Would you enforce any restrictions on how they can use those accounts? Would you allow them to contribute code to non-work projects for work purposes? If so, then their accounts would become publicly visible, bringing you back to your initial concern. You could just allow them to make the contributions with their personal accounts, but then you're creating a logistical pain point for them. Personally, I would encourage my employees to contribute code to other projects as themselves. This not only gives them a confidence boost, it is allowing them to gain valuable experience and to build their credibility.

In any case, I don't think it's worth the effort to have work accounts. The GitHub interface allows you to easily control who has access to what, so removing access is simple either way. I also don't think that having separate accounts really "draws a line" between personal and work projects anymore than the GitHub interface already does.

Also, keep in mind how you plan on dealing with this as your company grows. Are the policies you set in place now going to be scalable from a management stand point? Managing 5 accounts right now might be fine, but what happens when you grow to 20 or 50? But once you get to that point, maybe GitHub Enterprise will be an approachable solution. In that case I would consider figuring out if GitHub accounts can be migrated to GitHub Enterprise installs. If so, I can see that being a one positive reason to have work accounts.

share|improve this answer
Great points, thanks. Yes repositories are private. Regarding working on non-work projects at work, I'm not worried about that at all. It's just the account security. –  fiorenti Jun 4 '12 at 18:12
I've edited out that particular comment as it wasn't relevant. –  Jeremy Heiler Jun 5 '12 at 0:07
add comment

Not out of the question, and actually a pretty good idea.

Regrettable as it may be, you need to plan on your employees leaving the organization at some point in the company's life. How are you going to extricate their personal accounts from the company's repository at that point in time?

What are you going to do if the employee leaves on bad terms? In an ideal world, everything will remain professional and there won't be any animosity between the firm and the ex-employee. You would be prudent to plan for less-than-ideal circumstances.

While maintaining two accounts is a pain, your employees should welcome the opportunity. It provides a cleaner line between what is theirs and what is the company's.

Edit: Of concern here is providing a clear separation between the employee's personal contributions to projects X, Y, Z, etc... and their paid work on your company's product. Using a separate work account helps provide the delineation necessary to identify who owns what intellectual property and associated copyright.

For example, if an employee uses their personal account and contributes to both the company and Project X, how do you identify what role the employee was in at those points in time? Was the contribution to X on behalf of your company or their own personal discretion? Does the employee or the company own the copyright to that work given to X? For that matter, if you allow outside contributions to your company's work, how do you distinguish if the employee was an employee or if it was a voluntary contribution?

In a broader sense, say you have an employee who builds up a reputation acting on the company's behalf by contributing to other projects. When that employee leaves, how do you indicate that the personal user account is no longer associated with your firm? Serious brand issues can occur without clean delineation of what a particular account is for.

It's pretty easy to fall down a rabbit trail of ownership, brand, and copyright concerns when you start thinking through the potential scenarios. Using separate work accounts helps remove some of this ambiguity. The company needs to be able to lay claim to contributions made in its name.

It's not about the technical aspects of separating the user account out, it's the legal questions that can trip you up.

Note that this may be a moot point if your company's products are all released as open source under permissive licensing and / or you're not worried at all about potential branding issues.
(Hat tip to Paul Biggar for requesting this edit)

share|improve this answer
Thanks, I would also welcome this policy if I was an employee because of the mentioned reasons. GitHub's interface allows you to easily remove users' access from private repositories. I also assume that should an employee leave on very bad terms, in most cases he'll have enough time to do damage if he wants. –  fiorenti Jun 4 '12 at 18:19
I dont understand this answer. GitHub has fine grained access control. When an employee leaves, you remove their access from your organization. What's hard about this? Actually, it's easier to remove their personal account than it would be to "reclaim" their work account. –  Paul Biggar Jun 4 '12 at 23:33
@fiorenti: presumably, the user would also have a full checkout of the code, which would happen regardless of where the code is hosted! –  Paul Biggar Jun 5 '12 at 0:37
@PaulBiggar - I updated my response to capture some of the broader issues involved. It's primarily a legal attribution issue that leads me to recommend separate accounts. I have seen a number of cases where not separating personal from work accounts made for serious headaches in the aftermath. Everyone's MMV, and each situation has to be examined based upon the ethos of the company. –  GlenH7 Jun 5 '12 at 14:36
add comment

I'd vote "No". It's quite a bit of hassle for your developers and gives you security through obscurity: if someone's actively targeting your developers there's plenty of other attack vectors for someone to get your code.

Plus, as a startup unless you have a lot of magical secret-sauce-type algorithms at play someone getting your code would be embarrassing, and terrible, and obnoxious, but shouldn't result in a significant competitive advantage (who could legally use your code?) or cause you to go out of business.

Such a low order probability vs. developer productivity? I'd take developer productivity, but that's my calculus. :)

share|improve this answer
add comment

Since everyone seems to agree on the lack of employer’s need to separate both, here is my short experience having tried using my personal account on professional projects and open-source contributions made in the context of work.

Just to make the context complete: I was not asked anything regarding accounts, actually GitHub is unknown to most people at my workplace. I simply was able to get green lights to open-source the project I will be working on, and went with the least amount of work, i.e. using my personal account.

From an employee’s point of view, one thing I really hate: getting notifications on my personal email for work stuff.

From that observation, I went to realize it’s a blatant breaking of the professional / personal barrier: if I want to contribute to a project during my off time, I still get all updates from my work projects… And it can bring confusion for external contributors, who might contact you without knowing you’re off that project.

Then of course, there’s a balance to find with the fact that your personal reputation can gain from your work contributions. But then again, it might the opposite if your name gets associated with a poor project…

In the end, as the question is asked from the employer’s point of view, and considering all other answers: I would say there’s probably not much point in enforcing using work-dedicated accounts. But you shouldn't forbid it, so that employees who prefer to raise the personal barrier may do so, and perhaps hint about those risks…?

As a side note, regarding security, since there seems to be some easy dismissal in other answers:

Of course, a “work” account would not be any more or less secure than a “personal” account regarding passwords. But when you're using GitHub, you're allowed to push with an SSH key. And that key usually lies in one’s session… So, the personal account can compromise all work repositories with a simple personal computer steal (without password knowledge), whereas a dedicated work account would probably have its key lie only on the work machine, making it more physically secure (hopefully).

share|improve this answer
+1: Two points I didn't think of: emails and SSH keys. While having separate emails on GitHub is an issue, you can set up multiple SSH keys for your account. –  Jeremy Heiler Jun 5 '12 at 17:01
@JeremyHeiler What do you mean exactly by “having separate emails on GitHub is an issue?”. I am using three different emails (old one, current personal one, work one), once you've added them to your profile GitHub matches them with your account without problem :) –  MattiSG Jun 5 '12 at 17:14
I was referring to this gist. Are you saying that if you put your work email in your git.config on your work computer and add it to your account, all work-related notifications will be sent to your work email? If so, that's great! –  Jeremy Heiler Jun 5 '12 at 17:20
@JeremyHeiler Oh no ok, we had a minor misunderstanding of what is “an issue” with emails :) No, indeed, like I said in my answer, you always get notifications to your “main” (usually personal) account. But it is not an “issue” as in you'd need an account for each committing address: you can associate as many emails as you want with your account, but only one email gets notifications from your account. –  MattiSG Jun 5 '12 at 17:23
Sorry, yeah, I should have been more specific in my initial comment :-P –  Jeremy Heiler Jun 5 '12 at 17:27
show 1 more comment

I would say that should be a choice left up to the employee. One thing I would say is do not force them to use their personal github account if they don't want to. I was at a company that used GitHub and while it was not a requirement, I personally wanted to create a separate account. The main reason was to protect my person projects. I didn't want the company to try to say one of my personal projects was their's because it was under the same github account used for their comapny projects (not sure if that would ever hold up in court however I don't have much faith in the legal system when it comes to things like this). I think having that clean separate can be a good thing.

share|improve this answer
add comment

We are doing it in our company. I don't want to start a discussion "what is safer, github or a server under your table that everyone has root access, not sure if the backup is working, etc". Our approach was:

  • every developer, must create a new account, unrelated with his personal github account
  • it should use the company email.
  • It should be compliant with our security rules (login name and password requirement).
  • They cannot show/have any public activity.
  • It's company property. Not his/her account.
  • All accounts are connected with a company, random name as well. No public activity as well.
share|improve this answer
You can't enforce the password complexity requirement since you have no way to validate the GitHub password so why even have it? –  Ramhound May 21 '13 at 12:44
well you are saying that if you are not able to technically enforce something, you are not enforcing it. I'm saying that if, the a employee reads the security policy and if he sign it, knowing the consequences, it is an enforcement. –  VP. May 21 '13 at 13:38
I am saying you have no way of knowing something is not being done because you have no way to verify an employee created GitHub account's password. –  Ramhound May 21 '13 at 14:41
well, if for example, an account is compromised, and we, some how discover that the password was abc123, we can "responsibilize" the employee. I don't see a problem here. Another point: where is written that I ENFORCE it? I wrote it must (now I updated to should)... –  VP. May 21 '13 at 15:47
add comment

People are yet to trust the cloud based source servers. Github boasts lot of new age web companies signed up with them but the real fact is that, most people has their own servers for maintaining the source code. In my experience, most of them uses either Clear-case or SVN. Git is is yet to be adapted in an enterprise environment. Even the corporate mail servers aren't really appreciated outside the company's premises.

share|improve this answer
I currently work in a service company, trained them with Git, and most of their clients (like, big companies) are migrating from ClearCase, or getting ready to do so in their next projects… –  MattiSG Jun 5 '12 at 16:34
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.