If you don’t know what Git is, you soon will. It’s just scratching the surface of adoption by large organizations, and there are good reasons why it will grow rapidly. There’s great demand for Git by developers who have learned on and prefer that distributed version control system. However, enterprises need to account for issues around security/access-control, traceability, large-scale collaboration and automation that Git isn’t set up to handle well out of the box.

Let’s look at the current state of Git, review its strengths and weaknesses and suggest some actions or considerations for enterprises that want to optimize their product development for the next decade.

A brief history of Git

In 2005 Linus Torvalds grew so dissatisfied with the source control tools available to manage the work of maintaining and developing the Linux kernel that he created his own source control tool called Git.

Git was created for a particular task, not to be a general-purpose version manager. There is a community of contributors to the project, which sees fairly regular updates, but fundamental issues that affect its suitability for enterprise use remain largely unaddressed.

Let’s look at a few of the challenges that enterprises should consider when assessing their use of Git.

Products aren’t just source code

Using Git for any kind of digital asset other than program source code (typically in relatively small text files) is a challenge. The fundamental approach of Git—to create hash values to identify files—is very powerful but efficient only for text files. You should never put anything other than text files into Git.

But in a world where software is everywhere, companies need a system to manage both source code and other assets such as graphics and multimedia. With Git’s limitations, files other than source code are usually stored on a network file system or cloud-based file-sync-and-share services such as Box, Inc. or DropBox, Inc., where there is little control over access or audit control to track changes. When creating a deliverable product, all these different assets need to be brought together from the various repositories, which is difficult, expensive and error-prone. On top of that, teams often end up purchasing additional products for tasks such as managing the executables generated by build systems, for example, which Git can’t perform. And despite a number of proposals on how Git’s file type limitation can be addressed, none have been widely adopted.

My recommendation: Review how all digital assets—including configuration files—are managed and the number of tools involved. Look for tools that can version everything without inhibiting flexibility and speed.

Protect your assets from the start

Companies understand the importance of protecting the logical value of intellectual property (IP) by claiming patents or copyright, but not the actual implementation of that IP in software assets such as source code. Product content is your most valuable asset (along with the expertise of your staff), yet security experts focus on protecting the perimeter of their networks but are unaware of the security risks introduced by the tools that developers select.

This lack of awareness manifests itself in a number of ways. The first is control of access to the assets in the repository. The Git approach is to manage access at the repository level. The same access privileges are granted to every file for each user. You can split repositories to gain more control so that an external contributor, for example, has access only to a subset of the entire code base. But this procedure is far from ideal because it increases complexity and risk when trying to manage multiple repositories.

Secondly, Git provides little visibility into what authorized users are doing. That may be a problem for compliance or auditing, and it’s also an issue if the company can’t see if users are accessing files they shouldn’t or stealing IP.

My recommendation: Review the security of your development tools, especially content management tools. It may be possible to buy additional tools to increase security, but this also adds complexity. An ideal version management tool would have security as a primary feature.

Developers are highly valuable

RedMonk’s Stephen O’Grady suggests developers are the new kingmakers and that their contributions to the modern company are hard to overstate. Great programmers are valuable assets to every company.

The Git approach to version management is flexible and productive with its fast branching and versioning as well as its ability to work offline and privately until the work is ready to share. No one would want to compromise these advantages.

My recommendation: Implement tools that users love. For software developers, that choice might be Git, but that may not be the right tool for all contributors. So look for tools that are flexible enough to allow all contributors to use their preferred interface, whether that’s Git, a separate visual client or even a plug-in for design tools.

Does Git have a future in the enterprise?

In its current form, Git will likely continue to be a tool of choice of developers for the next several years, but as additional tools provide better support for all contributors and more of the capabilities that the enterprise requires, new tools and infrastructure will be necessary.

The time is right for a new take on modern development and version management. Learning from the great success of Git, a new generation of tools will emerge to cope with digital asset types and contributors. With no clear owner and road map for Git, these new tools will be something other than Git as we know it, although finding an equally entertaining name won’t be easy!

Image used under Creative Commons license via: Get Git Right