? Our’s is a typical old-fashioned large-scaled?project with a bloated codebase that reached 1,000?lines of code in about 3 years and keeps moving with a velocity of 300 lines a day. Yes, we do have design and code quality issues, but that?s the topic for another day.

One sunny weekend? we moved to Git with GitFlow workflow? covered in details by revered “A successful Git branching model and heavily supported by Atlassian

The first dust had settled in a month. We still couldn?t offer ?The? answer to life, the universe and everything? better than a 42, but we surely learned a few things about life in Git era.

?Two heads are not necessarily better than one….there is always someone to disagree with you.

Mistake #1: Pick a single?Git client to begin with.

We gave the team an option to choose from one of 3 Git clients – TortoiseGit, Eclipse EGit, and command line client. And we’ve run into a classic example of “The Paradox of Choice – Why More Is Less“.

Every time someone was stuck, they had to either find a buddy from their preaching camp or revise their tool allegiance.? That is, if there was someone around to help… If no one who knew ?how to? was available, the guys would attempt to find a solution on their own and with any tool ending up joggling between all three Git clients. You can imagine the slope of the learning curve, the level of productivity degradation, and the volume of pain cries.

Majority of folk chose TortoiseGit. It is a breather to get up and running with and it feels like home for those who come from using TortoiseSVN. And that was the very disaster – people felt they’d got a hang of Git without understanding the fundamental differences. Lion’s share of bad merges, lost files, and delayed pushes came from this group.

The curious ones stuck to Eclipse EGit. It can do a lot of things a command line client can. One limitation that we found out quite early was EGit could not prune dead branches, but we could live with that for a while. The real problem was ? the tool was very very buggy. We had to watch numerous tutorials on Youtube in order to find workarounds to merge files, resolve conflicts, reset branches, and much more.

The old school used the?command line client – the all-purpose tool until it came to conflicts resolution where a graphical client was much needed. At that point, it was a split of schools again: Eclipse, TortoiseGit Diff, or any other stand-alone Git compare tool.

?It may disturb you. It scares the willies out of me.

Mistake #2: Do not try to stop people from making mistakes.

Barely overcoming the ancient fear of cutting a branch, we couldn?t bring ourselves up to easily exposing off them. ?What if we need to come back in a week to fix a feature bug?? or ?My bugfix hasn?t passed QA yet!? were cried out a lot too often. Yes, we did study theory and conduct hands-on sessions, but obviously they were largely useless. What worked was to step back, let them keep original branches for as long as they like and then watch them cut a new branch when a bug in that feature had been discovered or the fix had failed QA.

?Not entirely unlike

Mistake #3: Don’t count on a tool upgrade to upgrade mindsets

The habit of isolating one?s changes from the rest of us by delaying syncing with SVN trunk till the ?you?ve got to complete this now? time caused us to update our local code bases once in a week or two. The pain of conflicts resolution was significant and regressions were introduced. Yes, there are ways to monitor and discourage such behavior, but once again ? we did have serious continuous delivery challenges. Indeed, many of us had accepted the fact that to avoid that pain we had to sync our code bases daily. Feature branches at first glance looked like a fallback to ?isolated development?. The point of daily syncing features with the develop branch and bugfixes with the release branch had to be hammered into each coding brain.

?If you want to survive out here, you’ve got to know where your towel is.

So to get ?The answer to life, the universe and everything?, we still have a few mountains to climb:

We don?t see how we can ease up the burden of merging bugfix branches into both release and develop branches. In theory – yes, we push bugfix into release, and after enabling the auto-merge the release will be pushed to develop. But by then, our develop is way ahead of release and the conflicts are the matter-of-fact.

Another unanswered question is competing pull requests. Say, I created a perfectly valid pull request, but my peers haven?t reviewed it on time and someone else?s request was merged before mine causing mine become a conflicting request. The next thing I know is that after I had moved onto another super urgent task, I have to stop my current work, switch to the old feature branch, withdraw the old request, merge conflicts, and repeat the push request again.

No questions about Git?s benefits, but porting a fast-paced large-scoped and organically grown project is definitely not a task for the faint-hearted.