Challenges in using Git Flow in a fast moving deadline driven project Praba Follow Feb 2, 2017 · 4 min read

I’d like to share some of the challenges we faced in following the Git Flow process in a recent project and how we are planning to address them. The context is that we needed to rewrite a web application which integrates with a handful of backend systems. As with any other project, we had a fixed date on which we had to go live. We had about 8 weeks to achieve this feat and had a team of 10 good developers.

Based on our previous experience with Git Flow, we naturally started with master, develop, feature branches with all of us racing to finish user story after user story. Please note that most of these problems are not with Git Flow as a process in itself, we had plenty of others as well —big team, small code base, weekly sprints ( I consider this as a problem), too little time and too many features, business getting hung up on deadlines and willing to compromise on quality — but Git Flow, under these circumstances slowed us further down. Here is a list of challenges we faced but please keep in mind that these don’t happen in isolation and I personally haven’t faced this in my previous projects with a smaller team and somewhat Agile projects (some wriggle room in scope and timeline).

Too many open Pull Requests

With a large team, we ran into this very soon. We were on Mon-Fri sprints which meant starting late Tuesday/Wednesday, we will have people creating PRs. By Thursday, there will be at least 5 PRs waiting to be reviewed. What’s even more challenging was that people move on to the next story after a PR is raised — this means context switching when there is a review comment or context switch to review the PR.

As a by product, we had way too many merge conflicts because when the 1st of 8 PRs get merged, some of the pending PRs are no longer mergeable.

Merge conflicts

While merge conflicts are unavoidable, we saw them more often, primarily because we had too many open PRs are mentioned above. This caused people to not fix merge conflicts till they knew that if they fixed the conflict, they wouldn’t have to fix again.

This also means context switching and more frustration for developers since now they have to do something not because the user story needed it but because someone else did something.

Big PRs

As developers, we know that we should be raising smaller PRs and frequent rebases from master so as to keep the merge conflicts at a minimum. What happens when 10+ developers do the same thing on a weekly sprint? One would spend the better part of a day doing just rebasing. This led to an interesting problem where people were not raising small enough PRs. We had PRs with 10+ files with plenty of changes. Sometimes people would merge these big ones first, but most often nobody wanted to review a big PR because it just took so much time and the PR will wait until a point where it’s costlier to not merge them.

“Please Merge This First” PRs

Though we know how to make better PRs, there were cases of A, B and C working on three different things and raised PRs and then D comes along with a change that breaks A, B and C which they figured out in the last day of the sprint. In some cases, it’s just that D’s PR simplified the rest of the PRs, in other cases it broke them and in a few cases, it invalidated other PRs. Nevertheless, D’s PR had to go in before the rest can be merged and we got the usual merge conflicts, too many PRs and the rest of the issues.

Needed more automation

We had an automated build job that ran test cases against pull requests. With too many PRs, whenever some PR got merged, we need to run test cases against all the remaining PRs to make sure they are still valid. We didn’t implement that — primarily for two reasons: most of the time, when a PR got merged, rest of the PRs had merge conflicts and secondly, it’s a very tight deadline and we didn’t really spend time on something which, in our opinion, had little value add.

What we are trying now:

We have started doing pair programming and also trunk based development which we seem to be helping ease the frustration with PRs a bit. We didn’t go the ‘pure’ pair programming way but started with a deployment buddy. When someone has their code ready to be reviewed, they are asked to find a buddy who will sit with the original developer, review the code, make changes, iterate — till the time the changes are deployed.

You might ask what if everyone is busy? How does someone find a buddy? The solution we arrived at was simple: you wait till you find a buddy. There is always plenty to do while you wait — write more test cases, refactor, go for a walk (we were working out of the basement, the literal basement, so people didn’t mind this), read/write a blog, go for a coffee. We should soon move to the pure pair programming soon (hopefully once the first deadline passes, but again, there will always be more deadlines).

Please read when Git Flow is appropriate and when it’s not. For the project in question, we are aspiring to get to multiple releases in a week so not requiring all the complexity of the Git Flow process is probably a good thing. But we didn’t optimise for our end goal up front (in fact, we didn’t expect to go live more than once a week when we started) but changed our approach once we figured our current approach is slowing us down. If you are not nimble enough to experiment with new processes, may be the processes are not the problem.