Git Enterprise Requirements
March 18th, 2009If 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.
March 18th, 2009 at 2:20 pm
Thanks for providing this perspective. It’s nice to see Git in a more general SCM context.
March 24th, 2009 at 3:49 am
Really really interesting article. I share any of the ideas.
I cited GitHub as an example of simplified but powerfull collaboration tool. But it is a closed app. What about gitorious? It seems to share many of the goals of GitHub, but it is free software. So, it can be “easily” deployed inside an enterprise.
http://gitorious.org/
March 24th, 2009 at 1:48 pm
Seems you forgot qgit (or qgit4), a nice and usable Qt-based GUI
http://git.kernel.org/?p=qgit/qgit4.git;a=summary
March 24th, 2009 at 8:32 pm
@Guyou-
Gitorious provides a good start for anyone who wants to put together a simple to use site for hosting Git repositories. And as open-source software, it can be extended to address security requirements and automatically add hooks to control workflows.
However, enterprises are likely to wait until someone else implements those features rather than developing it themselves. And the GNU AGPL license may also present a roadblock in adoption. It shouldn’t, but my experience with Insoshi, which also uses that license, has been that companies are concerned about the conditions under which they may be required to release source code. (This would only apply to modifications to the gitorious code, not any code stored in a hosted Git repository.) And one thing to keep in mind: enterprises are willing to pay for a closed application because support is included.
@Stefan-
I probably missed it since I don’t have Qt installed on my MBP. I’ve added it to the list. Thanks.
March 24th, 2009 at 11:27 pm
We’ve had good success developing *and* deploying without the use of addons.
A setuid update hook and git-shell solve the access problems over ssh, and a cobbled collection of shell scripts that tag and deploy tags run our deployment process.
Being able to work with the repository on production servers (in the worst case), and generate a patch has actually been a complete boon in our environment…. at least, I like to think so.
BTW, we’re a mod_perl shop, so we’re a little different than the normal git crowd.
March 25th, 2009 at 2:59 am
I work on a small team that develops shrink-wrapped Windows software. At first, we used a single, centralized git repository for the entire team. And you’re right–in that mode, git provides no security or access controls.
But after a few months of using git, we realized that there was a better way (at least for us): Every developer should get their own repository. In this configuration, only the team lead has write access to the main repository, and all patches are reviewed by the team lead. (Alternatively, you can give write access to a pair of senior developers, and have them each review the other’s patches.) This works surprisingly well, because git makes code review very easy.
The main repository has receive.denyNonFastForwards set to true, so no data can actually be lost (except by branch deletions). And we make sure that we have both reflogs and a robust offsite backup system.
Under this model, only your team leads have write access, and even they have extremely limited ability to destroy data. But team members can still collaborate and work independently of the team lead when necessary, and then submit the resulting code for review.
When you think about it, the Linux kernel is an order of magnitude larger than most enterprise projects, with a fairly draconian review process (or so it looks from reading lkml). And git was designed to operate well in that environment. So there’s a good change that some technologically-aggressive enterprises could use git today, provided they get the workflow right.
April 14th, 2009 at 10:30 am
Thanks for the interesting article.
You forgot about http://code.google.com/p/tortoisegit/
June 7th, 2009 at 7:01 pm
> Git punts on security and relies directly on the OS/filesystem and transport protocol
No, git doesn’t punt (”To retreat from one’s objective.”) on security. It’s agnostic, allowing you to implement your own. Git has support for “hooks”. For example, the update script can reject an update on the server based on anything (the contents of the file, the user pushing, etc. In fact, git has support for signing commits, so you could have an ops guy who only has authority to push updates signed by QA.)
> Integration with the “typical” Development Environment
> Example Workflows
> Simplified Administration
I only half agree with the sentiment that “git should be simplified for the masses”. There are some rough edges in git for sure. But at least it’s pretty hard to loose data without a stern warning first. Forcing one workflow on git is wanting to kill the goose that lays the golden egg.
But the “typical enterprise” could learn a lot from open source. It’s their loss if they don’t use git, we don’t care either way.
> How do I create a bare repository from an existing one?
cp -r repo/.git ~/bare_repo
> Which protocol should I use? git, http, or ssh?
Http is just a back-compatibly thing, don’t use it. Use SSH if you like encryption and don’t want to run another server.
> How do I restrict access?
To what? SSH and git hooks plug right into the infrastructure you already have, if you have a Linux server.
> How do I add and identify repository users?
Isn’t that what gitosis is for?
> What happens if I need to add a new repository?
You can create as many as you need, it doesn’t cost extra.
October 18th, 2009 at 8:32 am
Что-то наподобие у меня уже несколько дней из головы не выходит!
November 26th, 2009 at 4:07 pm
В общем-то согласен
Для меня это точно очень актуально 
January 16th, 2010 at 3:32 pm
Quoted your statement of git needing fine-grain access control on http://www.meetup.com/ocdrupal/messages/boards/thread/8087494/#33174391 which asks how to do fine-grained access control in git.