You know how it goes. Coder meets Project. They fall in love. They start to Develop a relationship together. Eventually they decide to write a History Book. They get one that is popular and start Committing to the pages, keeping a record of their life together. They love their History Book. They can open it up and the memories of how their relationship was in the past becomes crystal clear. They marvel at it. They develop a Workflow to keep everyday life running smoothly and keep History Book Conflicts at a minimum.
Their relationship Develops at record pace and the book is updated with frequent Commits. They spend entire days together, quite a few late nights and even the occasional weekend. Life is good for Coder and Project.
A Family of Branches
Their friends however have all started having Branches, and so eventually they start thinking about starting a family with little Branches of their own. It feels right and the History Book supports Branches. So they start Branching. A lot. It goes well at first, but with each Branch comes added complexity for the History Book. And the Branches grow.
Coder and Project try to work around it, modifying the Workflow, but the History Book becomes a mess. Frequent Conflicts arise. They argue. They fight. They cry. The Development of the relationship slows down and even the thought of getting more Branches makes them shudder. But they are committed, they are in too deep at this point. They need more Branches. It is painfully clear to them that the History Book wasn’t made for this big, complex family with lots of Branches, but they soldier on.
Time To Move On
Then one day they hear about another History Book. One that was developed to handle as many Branches as you could ever want. Coder and Project still love their old History Book, it is very familiar after all and has been with them for a long time, so they are a bit reluctant at first. Can it really be worth the trouble? But the more they learn about this new History Book, the more they realize that this is exactly what they need. And so the time has come to move on.
They spend weeks planning for it. There’s a lot to learn, many new concepts to grasp. They look around for existing Workflows and find one that fits perfectly with how they Develop. Of course the process isn’t painless and mistakes are made. But as the migration process is complete, Coder and Project happily continue Developing their relationship, Branching like bunnies, even taking it so far as to have new Branches off of their old Branches.
Wait… That analogy took an unexpected turn there. I think it’s way past time we dropped it. You get the idea.
Going Git
So, Percepio migrated from SVN to Git about a year ago now. The reason being we had a rather monolithic SVN repository that was a pain to work with and our Branching Workflow just wasn’t cutting it. Our team had grown quite a bit, and it was difficult to shorten our release cycle and develop new features separately. Now, I’m sure there were things we could have done differently to improve the situation slightly using the tools SVN provides, but in the end all the tools we needed and the Workflow we wanted were readily available in Git.
So we migrated to Git. We settled on the Gitflow Workflow since it fit perfectly with how we envisioned our release and development cycles. It didn’t take many days for all of us to fall absolutely in love with Git. The occasional loud exclamation of “I love Git!” or “Git is so awesome!” could be heard in the office as someone had wrapped up their Feature branch and, after Code Review and Testing, Merged it back into Development without negatively affecting anyone else’s work. Everything felt so streamlined and compartmentalized compared to the Dark Ages that were SVN.
Keep On Branching
However, there were things we should have done differently when migrating. We converted our large monolithic SVN repo into one Git repo. The large lib files we had should have been moved to a separate Git repo (or even SVN repo) and linked in using Subtrees or Submodules. The same goes for our various Tool projects. This separation can be done later, but ideally we should have done it from the beginning.
If you have experienced any of the problems with SVN mentioned above and are considering switching from SVN to Git, we highly recommend it.
Stay safe out there and keep on Branching.
By Erik