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.

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.

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.

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.