But beyond that I have some reservations.  At least for where Git is right now.

That hesitation is from the experience I’ve gained from performing start-to-finish installations of enterprise-class SCM tools including IBM Rational ClearCase and CA Software Change Manager.  What separates these tools from Git (and SVN) is that they address processes and workflows, security and roles.  And the enterprise world is all about that.

A standard installation of Git, on the other hand, is a blank slate.  You can do what you will with it.  Which is great for a developer who dreams of having that flexibility but gives SCM admins nightmares because they usually have to clean up whatever goes horribly wrong.

What allows Git to have a chance of making serious inroads into the enterprise world is that it’s open, relies on standard mechanisms such as ssh and has a hook system that is triggered by actions on a repository.  New functionality can be constructed around the version engine core.

So what exactly does Git need to have built around it?

My minimum set of requirements would include

1. Security and Access Control

Git punts on security and relies directly on the OS/filesystem and transport protocol (git:, http:, or ssh:) to control read and write access to repositories.  And current add-ons such as gitosis only address access at the repository level, not the level of branches, tags, etc.

Implementation of a unified security and a fine-grain access/locking mechanism is an absolute necessity before Git can be even considered as a serious enterprise tool.

2. Integration with the “typical” Development Environment

My experience with Git is with Rails and Mac OS X and Linux.  While this isn’t unusual in the startup world, it’s not the “typical” enterprise development environment.  That instead would be Visual Studio or an Eclipse-based IDE on Windows.

We need to support projects such as

• msysgit – a native Windows implementation of Git
• JGit – a Java GIT library implementation
• EGit – an Eclipse plugin based on JGit

if Git is to gain traction in the enterprise.

3. Repository Visualization

If you have development of even the slightest complexity, having a visual tool to view the branch structure and where commits are located is a necessity.  Some existing GUI interfaces include:

• git-gui (multi-platform tcl/tk)
• gitk (multi-platform tcl/tk)
• qgit (multi-platform Qt)
• GitX (Mac OS X)
• Git Extensions (Windows)

These tools, however, work on just local repositories.  Remote repository branching is only seen if you’ve fetched the information.

An enterprise tool will need to start from any “canonical” shared repository and then add branching information from local developer repositories in order to show the extended branch network.  This would provide a visualization of the development taking place across the organization.

4. Example Workflows

Git doesn’t mandate any particular development workflow.  Even the de-facto standard pull-request method of sharing updates is really a suggestion rather than an enforceable process (unless you’re working under a benevolent dictatorship).

Unfortunately you’re going to find that given n developers, you’ll likely see a minimum of n+1 ways of using a tool.

Example enforceable workflows for common practices including agile development, lifecycle management and deployment need to be created via the hook mechanism and made widely available.  An enterprise SCM team can then use these workflows as a starting point for customizing their Git installation.

5. Simplified Administration

Installing and using Git for a local repository is reasonably straightforward.  Configuring a repository for remote access is a bit more complicated:

• How do I create a bare repository from an existing one?
• Which protocol should I use? git, http, or ssh?
• How do I restrict access?
• How do I add and identify repository users?
• What happens if I need to add a new repository?

And if you have to host any appreciable number or sizeable sets of repositories, you need to start worrying about storage, load, and backups.

So is this at all possible? Can an enterprise-ready tool be built around a Git core?

Absolutely yes.

If you have any doubts, you just need to look at what GitHub has done with simplifying repository creation/forking, security and collaboration setup, and tools for visualizing the development network.  Or how Heroku has made Git a part of the application deployment process.

It’s just really a question of when someone’s going to put it all together for the enterprise.

That’s not a bad thing.  It simply means that it’s not any more or any less than what it claims to be: a distributed version control system.  And it’s very good at what it does.

But once you get beyond the initial repository setup and the standard add/commit cycle, you’re inevitably going to have a few questions:

• How often should I commit my changes?
• When should I create a new branch?
• What do I need to do to share my updates?

And these lead to a few more

• How do I manage all these branches?
• When should I merge the changes from my branches together?
• What’s the difference between a merge and rebase?

If you’re working in a team, you’ll probably also have

• What’s everyone working on?
• Do I have the latest updates?
• When do I submit my changes to the team?

And if you’ve been going for a while, you’ll want to know

• How do I simultaneously manage a release and a development version?
• Did that production fix get back into development?
• What did I just release?

At this point, you’re starting to slip into the realm of software configuration management (SCM).  Version control is just a small part of that.

The bad news is that Git doesn’t say anything about how you should do any of this (FYI, the pull request is more a suggestion than a formal required process even if it’s what Linus does).  It’s also the good news: You have all the technical capabilities you need but you’re not tied to a rigid one-size-fits-all process.

The key thing to remember is that Git isn’t the first VCS tool out there, even if it might be the first one you’re using.  There’s an amazing wealth of SCM knowledge to tap into.  It’s a matter of starting with what works and figuring out how Git fits into that.