Git as Corporate Source Control

In the small ecosystem of the development community that I spend my time in, Git is picking up steam as the SCM of choice. This migration that I have seen seems to be primarily for open source projects.  Recently Donn Felker made the statement "I think git (or something similar) is the future of VCS." on Twitter. I respect Donn, he's very smart, but is he right?

I see the advantages for open source projects where development is distributed. The software was developed initially to handle the development of the Linux Kernel specifically. In this way, it lends itself to the needs of this type of development. So if we extrapolate that further, it should be optimal for any kind of active open source development which are the types of projects with the largest liklihood of recieving updates from remote developers. I can also see the benefits of having a full repository locally as I keep repositories on a usb stick so that when working during my commute, I can checking, branch, or tag without having to wait for an internet connection. So even as a single developer, Git has advantages for me. But what about corporate America? Will we see wide spread adoption in these situations?

My guess is no, it isn't likely. I'm writing this as someone who has never used Git, and does not completely grok how Git or Distributed Source Control works. But here are the questions that I ask myself when looking at this problem.  I've worked at too many places where the development hardware was unnecessarily under-spec'd.  Getting anything over a 100GB of storage is difficult. Storage gets cheaper constantly, yet even with new machines the HDD's are laughably small. So, would we ever want to have full version history copied local? Hard to say, most repositories are probably quite small. The largest I have experience with is 2.5GB which is probably an extreme case with lots of binary files. Not unreasonable, even with a small harddrive. But I'd be curious to know what the average monthly growth of that repository is now.

My next question is around frequency of check-ins. As good developers, we know we should check in often, and if we do that with Git, that would maybe mean doing it often to your local copy, and then only checking into the central server once a feature is completed? I don't know, I guess a policy could be created and then ignored around this matter. How much code do companies want to risk on developer desktops/laptops? In this scenario, developers could be doing the "right thing" by checking in often, but they have another step complete... the actual commit to the central server. The way around this is of course to commit to the central server each time, and this could be me not understanding how distributed source control works, but that's double the work. Also, organizations want to have control over backups, and if they don't know how much source code is only sitting in developers local repositories, they don't know how vulnerable they are. Granted, with so many versions of the repository, that in a way is like backup, but each of the developers is vulnerable to losing the functionality they are working on if they have a harddrive failure, and even though they may have "checked in" the code, they lost it. Beyond that, I think that most development groups simply work in a process that Subversion is a better fit for. Similarly, most open source projects have processes that are a better fit for something like Git.

I'm sure some development shops with lots of talent will pick up Git and start using it. However, for the average organizations IT group, it seems unlikely that it will take off in my opinion. I remember when a company I worked for was looking to move away from Visual Source Safe, and we had two options, Subversion and Perforce. One of my arguments for Subversion was the fact that it was so prevelent in the open source community, that I was likely to encounter it again, and therefor it was a better skillset for me to have. And every job I've had since has used Subversion. To be fair, I did interview at a place that used Perforce, but I ended up passing on the job (the SCM had nothing to do with it). So, I know that I will end up working with and trying to grok Git, probably in the near future. At the end of the day, it is about choosing the right tool for the job. I think Subversion will probably be the right tool for most peoples day jobs, but there will probably be a lot more Git in the afterhours.

  
Comments
These are good points. There are other points as well to be made, for or against each position. I gave a presentation on this choice at a recent Southern California Linux Expo (see the website link on this comment, or http://snurl.com/k8zgl [svn-summit_open_collab_net] )

To some extent, this choice is going to be one of those that exposes the different priorities and needs of the users vs. the company, which is always painful.

Fortunately, there's a degree to which the extremes are approaching each other--for example, the Subversion community has added remote repository replication and cross-branch traceability, and is working to enhance off-line-work capabilities.

For now, though, you may have fingered the key decision point: given that policies /can/ offset some of these problems, is the organization satisfied with the level of noncompliance they'll inevitably get? If that gap's still too wide, a useful response would be to help out: for example, contribute to Subversion's off-line-work work, or contribute a git enhancement to automatically and asynchronously "push" changes to a central repo. All the interesting version-control tools are now open-source: there's no need to just wish things were better; you can actually do something about it!
I have several of the same concerns, and have been processing the same thoughts with mercurial. However, one important note is that distributed version control systems (DVCS) do not prohibit traditional, centralized repositories; they just enable more flexibility. Sure, they might encourage developers to work locally for a bit too long, but there is so much to gain from them. The way I see it, DVCS just adds more options/possibilities to the work model, while possibly requiring better-defined best practices.

Thanks for your post!
A lot of companies use source code management systems as an unofficial 'backup' in addition to other factors, but backups should be handled differently. Corporate IP should be protected by regular snapshots of info, but that's what backups to megaservers with intergalactic redundancy are for, not source control systems.

It doesn't make sense to have developers check in half-baked code that isn't unit tested first and administer it in a source code management system as if it was of coherent value. Developers should be encouraged to have their own complete sandbox to thoroughly test their ideas and code to ensure it's rock solid before checking in to a shared system where other people will be exposed to the changes.

For source code management, a distributed model is the way to go! It works much better for developers, and if big brother can grasp the concept that their IP can and should be protected by backups, there is no downside for them. It's a win-win scenario for individual developers and the companies they serve, since increasingly distributed developers can be much more productive.
I think what is needed is a corporate github.com-site.

An intranet-site similair to github, when the developers can publish their own repo and others can pull from it.

And where their is a central repo, where (maybe only some) people can push to.

Just is, I've not seen anyone (other then fi.github.com) create one yet.
I forgot to add, that a central repository in the same way as with previous systems isn't such a good fit. I think all the modules and parts should be split up in seperate repositories so you don't need to download gigabytes of files.

Maybe gitosis could be a way to handle developers creating seperate repos.
As I'm a little new to git, I've now learned it has submodules to deal with splitting things up in seperate repositories.

I'll shut up.
LH
Ok, this is a little bit old, but if someone finds this (like me) via google:

@Lennie:
There are such solutions, like indefero or gitorious, that can be installed in an intranet. Both are open source.
dk
I agree with Rory. Don't use version control just as you backup mechanism. With a system like Git I am able to create micro commits that would just make a mess on a central repository and instead I compose meaningful commits to be pushed out. Even with local only commits I still push changes to a common repo multiple times in any given day.

Another advantage to a dvcs is the speed! Having it all right there locally means I never have to wait. I was a huge SVN fan but now that I've been on a Git project I don't think I'll ever look back.

I think you nailed it when you said average IT shops probably won't pick it up. So if a developer wants to be better than average I suggest you learn to use a DVCS like git or hg.

-dk

Comments are Closed

Blog Home
Recent Posts
Mix11 Video Downloader
Pdc 2010 Downloader
Clearing the ClickOnce App Cache
VB.NET Gotchas for C# Devs
Dreamhost 1 year Special
Can I Suggest Bit Torrent?
Moq and VB.Net are Frenemies
Google Buzz - Impressions
O Rly? Intellisense requires XML + DLL
Self Documenting Code - FAIL
The 'F' in TFS is for 'Friction'