We are in the process of evaluating GiT for our developers to use for source control. We already have CA SCM, but they said it does not branch well so they want to use a different tool just for their development state.
One of the requirements is to lock down the GiT repositories so that each team can only update their code. I'm not seeing a way to do this without giving the developers access to the file system where the code is stored.
We have LDAP and would like to use that so that we don't have to manange security seperately. We would give the team read/write/update access to the folder on the file system, but that would not stop them from updating the code outside of GiT.
Am I missing something?
I am not too familiar with Git, but what kind of branching problems are you having with SCM?
There are different branching strategies that can be done with SCM. You can turn on concurrent development, which allows branching of individual items, or you can create snapshots of production and create additional projects. These additional projects can then be cross project merged back into the original line. Just some thoughts there.
Personally, I'm not having any problem with branching using CA SCM. I love the tool and I think it works great. The developers want to "branch on a branch" which CA SCM doesn't do, and GiT does. And as the CA SCM administrator, I lost the battle, so they are going to use GiT (for now).
My original question was about securing the GiT repositories. Do you have any information on that?
Well, one thing you seem to be missing is, git is easily (I'd even say "normally") accessed via network protocols (choose http, ssh, or both), which saves you the "access to the file system" problems.
More precisely, you typically have one central git repo accessed and secured that way, and you build releases from that one. The git model also puts a complete repo at each developer's desk, which is where it gets most of its speed and branch-and-merge slickness. But you don't need to worry about securing these local repositories from developer mistakes, so long as you stick to the build-from-central model.
Developers develop in their local repositories, but push up to the central (causing their changes to appear in the central, but on a branch not the "master"). Then, they issue a "pull request," which means someone with suitable authority and testing responsibility merges the branch changes into the "master," whence they can be built and released.
If your release situation is complicated enough to need it, you can have separate branches in the central, say one for each release, all managed in the "master" way, and a plethora of developer branches, worked locally and pushed to central, then pulled to the appropriate release branch for build and release.
Let me try to explain our set-up, then maybe you can help me figure out how to secure it.
GiT is installed on a windows server. The GiT back-end (where the repositories will reside) is a file-share on the SAN. We have several project teams who will be using GiT for source managment. I need to secure it so Team1 cannot see Team2 code, etc. (That's the easy part). In addition to that, I need to lock down the back-end so that the file-share can only be updated by GiT. If I use LDAP groups against the file-share, I'd have to make them READ/WRITE/UPDATE for GiT which would allow the developers to have direct access to the code instead of using GiT - which would kill my audit trail. I would like to use LDAP groups so that I don't have to maintain seperate security somewhere else for the GiT repositories.
I don't think security at the file-system level, as you propose, is going to work for you. The problem is that git stores all its files and directories in a database. I think you're wanting to allow different people different rights in different parts of the git-managed directory space; but the file system isn't able to see the "real" or meaningful part of the address space, only the database, which simply does not have the familiar, human-oriented structure.
I think you should access your central repository only through network protocols. This allows you to use file-system permissions to block any access at all by any users except the pseudo-user as whom the git server runs. No humans have file-level access at all. The security model you want, the one based on human identities and sub-trees of the working copy, is then implemented in git, through the kind of procedures I mentioned.
Some references to help you achieve this:
http://code.google.com/p/msysgit/
http://www.timdavis.com.au/git/setting-up-a-msysgit-server-with-copssh-o...
http://serverfault.com/questions/58425/setting-up-git-repository-on-remo...
http://stackoverflow.com/questions/1482824/setup-a-git-server-with-msysg...
We're using GIT via GitHub and each day it seems I'm finding our something new and undesireable about the tool. I'm do not recommend it for mature software development. My development team wastes literally days in figuring out how to work with the repository. Most try to avoid any contact with it which is even more detrimental to team development.
GIT as a whole isn't driven for the SCM world. It's a developer centric version control tool which isn't bad but it doesn't support some of the most basic SCM needs.
For instance, GIT doesn't allow custom hook scripts in the repository (which would be the way I'd lock this down in Subversion). I wanted to have a hook script (again something very basic) that would check for a ticket number in the comment. Since Git repositories don't 'clone' the hooks area to the workarea, it's incapable of checking.
GitHub provides 'some' surface level admin capabilities although nothing like I could do with PVCS, Clearcase, Subversion or even CVS. You can use 'Team' membership to identify access to repositories (which you've declared are private). Through this you 'could' restrict permissions for write access.
Good Luck if you go down the path of choosing Git.
As a potential compromise (as we're forced to use this tool as a company prerogative), I'm currently evaluating using the Git-SVN bridging capability (git-svn) which incorporates using Git as a valid client to a SVN server, so your developers can use all the local features of Git and then push back to a Subversion server.
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.