We have an Enterprise Java project with roughly 500,000-lines of code. It goes without saying that such a project needs good version control. But what should such a project use?
Subversion has worked for us up until now on the project, but it is falling short of meeting our process and productivity needs. Without effective merging, branches won’t be used no matter how cheap they are to create. The only Subversion branches we have ever created have rarely stayed in sync with upstream and always led to dramatic merging ceremonies, worries about regression and code loss. To make a long story short, Subversion supports parallel development, but makes it so difficult to use effectively that you are better off avoiding it altogether.
Git handles our roughly 500,000-line Enterprise Java code base with ease. It is faster for one developer to git svn clone and then have his peers git clone than it is for each developer to checkout simultaneously from Subversion. Once done it gives every developer on the team offline access to the entire project history. The offline access allows developers to do complex historical comparisons that would be slow enough in Subversion to discourage developers from doing them. Git not only makes certain reporting operations fast, it makes them practical and productive to use.
In terms of support for multi-tasking, I am up to four features in my single Eclipse project now and none of them interact or interfere. Git lets me cast them aside to fix a critical issue and then resume where I left off. There is nothing quite like seeing a single view of a code base of this size converted within seconds from one large feature to another simply by switching branches.
It certainly also helps that Git works solidly on Windows as well. I found that I had to configure msysgit to leave line endings as they are rather than converting them to avoid problems with our legacy code base. Other than that the defaults are solid and Git makes it easy to integrate tools like KDiff3 for Windows to allow graphical merging and diffing.
What do we get by switching to Git? Developers get to fearlessly develop features and fixes with its first-class support for branching and merging. QA and Product Management gain interactive control of the release by actually being in the path to committing developer changes to the released code repository. All in all Git is a win for people process over technology. Git is an SCM for companies that value putting people in the driver’s seat of the release process.