gitguru

If you’re an individual developer or a small team, I wouldn’t think twice before recommending using Git.

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.