With a rapidly growing team and ever expanding code base we were looking to transition our repositories to something with better features than svn while also applying an easy to use branching methodology, the following briefly describes our transition from svn to git and then gitflow, the reasoning behind it and the obstacles we faced.
Subversion (svn) had its advantages, it was simple to use, fast and reliable. A user could quickly get up and running with a simple commit, pull structure and the versioning was easy, a simple integer commit index. However branching proved difficult, we had little experience with branching and no set branching model so what little experience we did have was fraught with problems. It was also getting more and more difficult to maintain such a large code base on a single branch.
So the decision was made to move to git.
git brought with it fantastic speed, quick branching and great community support, other companies and the internet as well as hosting services such as github.com have flourished under the ease of use, versatility and portability of git. With all the power of the command line as well as some more friendly GUI tools such as SourceTree and Smartgit, it offered everything we were looking for in a new code management software
As git has support for svn in the git-svn module, transitioning was painless, with help from a tool called https://rtyley.github.io/bfg-repo-cleaner/ we were able to remove a great deal of unwanted history and trim the size of the repository from 5Gb down to 600Mb, decreasing the checkout time considerably.
Now that we had git and its awesome power, we realised that now that we had all these branches what were we going to do with them, with pull-requests, local and remote branches we had a lot of options but how best to tame this beast?
After reading and hearing great things from colleagues and the internet, we introduced git-flow onto our repositories, we were impressed with its simple branching strategy and great tool support in Sourcetree, Smartgit and cli and its (almost) zero setup.
Through the use of gui tools we had a simple click based interface making it effortless for users to start and finish features, hotfixes and release branches all without having to worry about the underlying git commands, making it seamless and reliable. The automatic tagging of versions made rolling back errors a breeze.
The following image shows the relatively easy progress of development through a release, with time moving down you can see the flow of commits into each branch, continuing and culminating in a merge to master:
We found initially that git had quite a steep learning curve for people who were not used to it, with ‘everything being a branch’ and having to pull and merge just to push your own changes was challenging for some users. Gitflow helped with this as well, the simplicity of working in a personal feature branch until all work was complete helped reduce unnecessary merging and conflicts. However gitflow also makes it easy to push your feature branch to the remote server, for team review or a multi user feature.
The eclipse ide was another hurdle in the git transition while we figured out its own quirky way of working with a git repository, however these problems were overcome with training and practice.
Going forward we will focus on more employee training in ‘gitfu’, helping them solve any merging headaches themselves as well as helping them embrace the versatility and flexibility of git.