Git-Based Source Control in the Enterprise: Suggested Tools and Practices?

Posted by Bob Murphy on Stack Overflow See other posts from Stack Overflow or by Bob Murphy
Published on 2010-03-05T00:49:24Z Indexed on 2010/03/09 6:36 UTC
Read the original article Hit count: 284

Filed under:
|
|

I use git for personal projects and think it's great. It's fast, flexible, powerful, and works great for remote development.

But now it's mandated at work and, frankly, we're having problems.

Out of the box, git doesn't seem to work well for centralized development in a large (20+ developer) organization with developers of varying abilities and levels of git sophistication - especially compared with other source-control systems like Perforce or Subversion, which are aimed at that kind of environment. (Yes, I know, Linus never intended it for that.)

But - for political reasons - we're stuck with git, even if it sucks for what we're trying to do with it.

Here are some of the things we're seeing:

  • The GUI tools aren't mature
  • Using the command line tools, it's far to easy to screw up a merge and obliterate someone else's changes
  • It doesn't offer per-user repository permissions beyond global read-only or read-write privileges
  • If you have a permission to ANY part of a repository, you can do that same thing to EVERY part of the repository, so you can't do something like make a small-group tracking branch on the central server that other people can't mess with.
  • Workflows other than "anything goes" or "benevolent dictator" are hard to encourage, let alone enforce
  • It's not clear whether it's better to use a single big repository (which lets everybody mess with everything) or lots of per-component repositories (which make for headaches trying to synchronize versions).
  • With multiple repositories, it's also not clear how to replicate all the sources someone else has by pulling from the central repository, or to do something like get everything as of 4:30 yesterday afternoon.

However, I've heard that people are using git successfully in large development organizations.

If you're in that situation - or if you generally have tools, tips and tricks for making it easier and more productive to use git in a large organization where some folks are not command line fans - I'd love to hear what you have to suggest.

BTW, I've asked a version of this question already on LinkedIn, and got no real answers but lots of "gosh, I'd love to know that too!"

© Stack Overflow or respective owner

Related posts about git

Related posts about best-practices