Git has no built-in access control features. If that seems a surprise, one reason is that the Git project specifically considers access control to be outside the scope of a version control tool. Another reason is best practices with Git typically result in many small repos, in contrast with the gargantuan repos often found with centralized version control systems. Having logically unrelated code resident in separate repositories means we can control access through authentication, where a user either has zero or complete access to a repo.
Enterprise software development is often subject to demands not found in the open source landscape where Git was born. Code bases can have interdependencies that may prove too entangled to refactor into individual Git repositories. Or projects have migrated from a centralized version control system where large files are mixed with small, creating trouble for Git’s assumptions about how large a large repo can be. Sometimes, we see product code assembled from a combination of contributors, combining code from outside-the-firewall contractors with inside-the-firewall employees. All of these situations can create access control needs that go beyond all-or-nothing repo access.
Far reaching effects
The Git project’s decision to leave access control as an exercise of the user has another important effect: it invites increased diversity in choice of access control tooling. Rather than most groups falling in line with, for example, Apache controls for Subversion, we typically see a large organization sprout a variety of open source and commercial solutions. Infrastructure seeks consolidation, so we see IT/SCM teams sometimes scrambling in order to avoid becoming responsible for supporting a large number of new technologies of questionable pedigree.
This situation is compounded by the fact that Git can easily, and often secretly, be used by developers still tethered to a centralized system. This means Git often obtains a significant beachhead of adoption, and a divergent mess of ad-hoc technology stacks along with it, before your enterprise SCM administrators step in.
Another common situation is where developers in a company are gradually shifting from other systems to projects using Git. In these cases they may spend some or possibly long periods of time accessing older as well as new systems. We believe we will see Subversion and Git co-deployed for an extended period in enterprise development environments. That’s why managing access control across Subversion and Git deployments is part of the core functionality of our new Access Control Plus product.
Looking ahead to solutions
This series of posts is about challenges more than solutions. I’ll be speaking about solutions for Git access control at our Subversion & Git Live conference this May. See you there!