Is Git a Good Fit for the Enterprise
Git has quickly become the version control system of choice for many developers. Originally developed in 2005 by Linus Torvalds, Git is relatively easy to use, has good repository integrity, and has a distributed architecture. But Git also has some limitations and can be challenging to support for large scale enterprise use.
When establishing and supporting version control systems, one approach is to use one of the popular software as a service-based hosting services such as GitHub or Bitbucket, which have the advantage of requiring minimal administrative work and overall adoption at very low cost. However, many organizations cannot rely on an external service provider to maintain their source production baselines. In this case, these organizations often use one of the available Git frameworks such as Stash or Git Enterprise. I have worked with a couple of organizations that found using Stash was quite acceptable.
The next challenge is ensuring that your Git adoption is consistent across your organization. Developers usually try to use whatever approach worked well on their last project. I have seen this become a real problem when developers try to use their old procedures after joining a new team. This approach can result in inconsistent procedures that can be confusing and result in mistakes. I focus on working with the existing stakeholders to define a common use case for handling tasks such as tagging baselines, comments on commits, and, of course, variant management.
Branching and merging in Git, although better than some other open source version control systems, can still be confusing and lead to costly mistakes. My focus is always to develop training to enable the developers to use a common set of consistent procedures. Training is the most important success factor in any enterprise version control system adoption. When teaching a version control system, I teach the release procedures, including application build, package, and deployment. Version control system administration is another important consideration.
Backup and recovery procedures are essential, along with user account authentication (using LDAP), installation, configuration, and support for the infrastructure itself. Git projects need to be configured to allow read-only access for some stakeholders, such as other teams creating interfaces, while providing read and write access to the team members who are writing the code. Keep in mind that you may have to support many teams and projects, each with their own schedules and requirements. Another issue is coexistence with legacy systems or even commercial systems.
Git may be the choice of many developers, but some build and release engineers prefer robust commercial tools that can coexist with their production Git environments. Scaling Git for the enterprise can result in significant capabilities at a very low cost.
In the comment section below, please share your best practices with scaling Git for the enterprise!
