Git Enterprise Requirements

March 18th, 2009

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:

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.

35 responses

  1. Michael Hartl comments:

    Thanks for providing this perspective. It’s nice to see Git in a more general SCM context.

  2. Guyou comments:

    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.

  3. Stefan comments:

    Seems you forgot qgit (or qgit4), a nice and usable Qt-based GUI :-);a=summary

  4. long comments:


    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.


    I probably missed it since I don’t have Qt installed on my MBP. I’ve added it to the list. Thanks.

  5. erikh comments:

    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.

  6. Eric Kidd comments:

    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.

  7. Maxim Filatov comments:

    Thanks for the interesting article.
    You forgot about

  8. Anonymouse comments:

    > 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.

  9. DestinyArchitect comments:

    Quoted your statement of git needing fine-grain access control on which asks how to do fine-grained access control in git.

  10. Sitaram comments:

    fine-grained access control for writes: try gitolite, it’s pretty damn good

    PS: Im the author so I’m biased ;-)

  11. Ray comments:

    I think that some people are missing the point here. Leveraging the current callbacks framework exposed by git is anything but granular and access control ultimately comes down to a “gentlemen’s agreement” of sorts between the developers (anyone who has any push access) and the repository maintainers. The original poster above here was quite correct, git access control is nothing more than a shell game, it is offloaded to the OS/filesystem or obfuscated with a callback hook. The ability to push into a git repository requires that the pusher have write access (or magic spells), and with that write access (or the aforementioned spell-craft) they can ultimately do as they wish.

    Don’t get me wrong, I love git and I use it for all of my personal development and a good deal of my work development as well, but until git has a real, inherent access control mechanism it will never be taken serious in the enterprise environment.

    Anonymouse comments:
    June 7th, 2009 at 7:01 pm
    > But the “typical enterprise” could learn a lot from open source.

    and the typical script kiddy could learn a lot from the enterprise.

  12. Bruno Bossola comments:

    We are a group of developers working in a large enterprise (one of the biggest Telco in the world) and since we adopted Git we recognized almost all the issues mentioned by the op. Because of that, we have been working, since last year, on a solution for those problems. We have developed a host based service (that can be also installed on site) that delivers a nice web interface to manage your repositories, your users and groups, and security at very fine grained level

    1. Security and Access Control
    We provide read/write access control over repositories and, at branch level, control over READ / CREATE / PUSH / PUSH-FORCE / DELETE right out of the box trough a pleasant web interface.
    Every access to Git repository is secured via SSL/TLS with FIPS 140-2 certification and SSH Protocol, required for Enterprise-wide source code repositories. GitEnterprise does not rely on the system SSH Server and then does not expose any security risk on the underlying OS.
    All the external access is centrally audited with ability to extract the information needed for SOX Compliance Report

    2. Integration with the “typical” Development Environment
    We are currently evaluating the feasibility to drop some work on the Git plugin for Eclipse, but this is not part of our core scope

    3. Repository Visualization
    A web interface is available for repository visualization, and it includes a full repository navigation system based on the popular CGit ( ).

    4. Example Workflows
    We think this must be agreed within the enterprise / project scope. What we have in our enteprise is a de-facto central repository that produces the official builds then are taken trough the delivery process (which, in our case, is composed of three level of testing and two deployments)

    5. Simplified Administration
    The administration is really simple. Everything is done trough a simple web interface. You can import, connect or define your SCM users of your organization, setup security domains and groups, list you repositories, identify users, groups and permissions, create and destroy repositories. Almost everything you can think of is in place, well, at least all the things that were requested to us by our customers until now :) (but we’re happy to improve!)

    GitEnterprise (that’s the name of the thing) is also available on a freemium base: you can get a 10 users / 1GB account for free. We encourage everyone to give it a try and provide us some feedback!

  13. Git Enterprise comments:

    It should also be noted that using native git you can currently commit in behalf of someone else, so “stealing” his identity. With GitEnterprise this is currently (of course) not possible, as it validates the committer email/name with the profile corresponding to the credential used to access the repository. This is a huge advantage for an enterprise environment, believe me :)

  14. David Miller comments:

    GitEnterprise sounds excellent. i have passed the info along with the gitolite reference to our IT team in Stockholm

  15. david miller comments:

    Ok our IT team in Stockholm say the gitolite is extremely interesting and will be in touch for more specifications. thanks again for this info

  16. diy solar comments:

    Are you a solo web developer or maybe you work as a team? Well, if that’s the case, you would want to use Git. So what difference does it have from all the other installers out there? Well, for one, once you install Git. It’s standard installation is a blank slate. You are very much free to do whatever you please with it. what does every developer dream of? It could be the liberty and the flexibility that can be offered to them while using the said program.

  17. Stewart comments:

    I got some points of you. I know this distributed revision control system really helpful but for me it’s a little difficult to use this software. Let alone I am only an individual developer so I won’t use Git.

    Anyway, thanks for sharing it although I don’t use Git, I got some points of there.


  18. vasya comments:

    Hi !

  19. Chaser Cruz comments:

    Installation of Git is an advantage though it is a blank state. You can do whatever you want with it. It is a great idea for those dreamers to have a flexibility but still having problems and needs to clean up what have done wrong. Another thing about Git is that you can import and connect your users organization, Whatever you think is in properly place.

  20. Marina comments:

    Пишите больше!

  21. Martin comments:

    1. Security and Access Control
    Using a distributed version control system like git, you need write access to your own remotes (ssh) and others need read access (git protocol or possibly http). It is as simple as that.
    All other wishes are just based on a misunderstanding of the distributed concept and that is very common. Eclipse project and their hooks for validating committers is an extreme example… sad…

    In a corporate environment you need to protect all data that you don’t want to share with the world. The protection of secret data in most places is usually a joke and there is no real point in asking for more in the DVCS so putting the git: and http: servers behind the corp firewall would keep the data in the DVCS repos as (un)protected as the rest of the secret data. Local repos should be on encrypted drives if you care.

    2. Integration with the “typical” Development Environment
    Plugins are typically something that you should avoid. It creates extra work because most people are using DVCS for many different kinds of projects. That means, either you learn you DVCS once an for all or you learn how to use it in a variety of different ways depending on what IDE or other environment you are using or what plugins you currently like.

    3. Repository Visualization
    Use gitk and git-gui or install a git server somewhere. Gitorious works well and is reasonably easy to install on your own servers if you follow the instructions.

    4. Example Workflows
    Use the same as Linus… Why would you mess up things by using a non distributed workflow just because you are in a corporate environment… Except from start using Git, projects leaders must make is clear to the subordinates that the work is not done until they have pushed it to their public remote so that the project leaders can pull. And this is the most difficult thing in the whole chain… to make project leaders understand why they need to use a DVCS at all…

    5. Simplified Administration
    I have installed a gitorious server… It works wonderfully well but it contain lots of features that you really don’t need, like multiple committers for one repo and teams etc… Administrative effort is basically zero… Users are registering themselves and they create repos or clone existing repos by themselves.

  22. Addyson Cleveland comments:

    Good feed No wonder why Christian Dillstrom had a book mark to this blog post, so you are doing a great job as mobile and social media marketing whiz provides a hyperlink to you.

  23. John Gietzen comments:

    I am putting together a Git solution for the Windows Enterprise at:

    We are adding access control in the coming releases, and workflow in the next. It would be great if your could take a look and tell us what you think!

  24. facebook login comments:

    Nice post about gitguru » Git Enterprise Requirements. I am very impressed with the time and effort you have put into writing this story. I will give you a link on my social media blog. All the best!

  25. Michael comments:

    What are the system requirements for Git?

  26. Alex Beamish comments:

    This post is three years old, but some of the comments are more recent, so I thought I’d address some of the points you’ve raised.

    Git is just a version control system. In the Linux/Unix context, it’s a tool that does one thing well. You are, of course, free to add more tools and build a more comprehensive system if you choose. That’s the Linux/Unix way.

    In terms of security and access control, the authorization for my git installation is provided by SSH authentication, and for access control, I have installed gitolite [1]. Gitolite provides very good control on a per-repository and per-branch basis, as necessary.

    My users have successfully used msysgit [2] for Windows and the EGit plugin for Eclipse to provide integration with their normal workflow. This works very well. In my presentations to the Engineering department, I’ve demonstrated gitk (for visualizing branches) and git gui (as an alternative to issuing commands on the command line), and my developers have found that git-cola is also an excellent GUI for git. There’s also TortoiseGit for Windows. Yes, these tools work only on what can be seen locally, but that’s because git is a distributed version control system (DVCS).

    There is plenty of information available on the main git web site [3] on all of these topics; git is a great version control system, and stands up very well when compared to other systems [4].


  27. Peter comments:

    More and more git servers provides enterprise features : is an example of a such system.

  28. Lothar Schubert comments:

    A global chip manufacturer is managing Git and Subversion with one common platform at enterprise-scale, integrating Android mobile development with traditional software projects:

  29. 06/01/2013 o 00:49 tracks back:

    06/01/2013 o 00:49…


  30. Penny Clicks comments:

    I believe that is one of the so much vital information for me.
    And i’m glad studying your article. But should observation on few general issues,
    The web site style is ideal, the articles is in reality excellent : D.
    Just right process, cheers

  31. Google comments:

    Observers maintain the item displays a new coherent
    approach, one thing thus low in your culture, that it’s
    not necessarily realised by simply all. * Let you know there are things you can do to improve y0ur ranking.
    Any time you create new content or share new links on your website or
    blog, be sure to do so by diversifying all of the link and
    anchor text you implement, regardless of the market you represent or the
    industry you are working in.

  32. Muthu comments:


    I need the information for the below:

    Hardware requirements for (Server & Client)



    Superb blog! Do you have any helpful hints for aspiring
    writers? I’m planning to start my own blog soon but I’m
    a little lost on everything. Would you suggest starting with a free platform like WordPress
    or go for a paid option? There are so many choices
    out there that I’m completely confused .. Any tips?

    Appreciate it!

  34. mental health residential treatment center tracks back:

    mental health residential treatment center…


  35. cheat head soccer tracks back:

    cheat head soccer…

    gitguru » Git Enterprise Requirements…

Leave a comment