Git Puzzles: Missing Pieces to Git in the Enterprise
It’s been a little over a year since I hypothesized that the collision of Git and Perforce in the enterprise would initiate a creative solution where everybody wins. In the year since, we’ve seen that vision widely validated by real world examples from our customers and elsewhere.
Reality has evolved past the initial conflict between the two types of tools, and now we see Git deployment in the enterprise appearing more often as a base requirement. While Git alone can work very well for small teams, deployment to thousands of developers in a geographically distributed environment creates special and difficult challenges for Git enterprise architects.
The result is that companies may begin to struggle to deliver the “Git experience,” loved by developers, at scale. Here at Perforce, we are dedicated to helping deliver the Git experience at the same scale to the same types of companies we’ve already supported for over a decade.
Let’s take a look at some of the contributing factors limiting Git in the enterprise. You might not face all of these right away but I’ll wager you will feel most of them eventually. And if you don’t see your problem here, please let me know!
With Git, you get the entire history with every clone. That’s good, because your history is local. But it’s bad, because as time goes on, your repo grows indefinitely. Git doesn’t provide an easy way to prune history, and besides, wouldn’t you rather keep access to all history forever?
The most common response I’ve seen to using large binaries with git is: don’t. Or, use an asset server. To me, that’s code for “don’t use version control”, and a non-starter for many types of enterprise projects.
Geographically Distributed Teams
Say you have an office in California, and an office in China. Clone times on the LAN in California are creeping up into the 60 minute range. What’s the clone time from California to China going to look like with connection speeds a small fraction of a local clone? If you instead push to a shared git repo in China, how much harder become the merges between diverging code bases on the two continents?
The two approaches most often seen with Git are:
- separate repos for each shared code body, or
- duplicating the shared code into all the repos
Each of these approaches has its own set of problems. Wouldn’t it make more sense to use a git repo as a view into a larger, shared codebase?
Reinventing Corporate SCM
We’ve also seen very smart teams at enterprise shops solving many of these problems on a case-by-case basis. At some point they realize they might be reinventing corporate SCM, one script at a time. Might it make more sense to leverage existing version management solutions?
James Creasy leads Product Technology at Perforce Software, indulging his passion for exploring emerging technologies. Formerly lead developer and product architect for several Perforce products, James is now laser-focused on helping advance the company’s mission to Version Everything. When he’s not playing the role of technology strategist, James races cars, plays classical piano, and paints portraits -- but never at the same time.