Teaching people to use pull requests for development is a disservice.
GitFlow is used by many in industry, and because of this is taught in universities. This is a mistake. We should teach students trunk-based development instead. It’s builds more quality into the work, and helps students learn to collaborate as a team.
GitFlow is great process for low-trust environments, where people don’t meet each other for collaboration. This is why it works well in open source. People contribute pull requests to open source projects, someone looks at them to approve, and the software moves forward.
Using GitFlow in a business environment is wrong
People should be talking to each other, collaborating on the work together. There should be high-trust in this environment, even when bringing new people into the team.
People should be doing the work together, pairing, or working as an ensemble. GitFlow encourages people to work solo, and to then interrupt other people’s work with pull requests for review. This means they are done as a checkbox exercise in many instances.
GitFlow slows down work and encourages people to work without talking to each other and collaborating on the work. All of the pull requests and branches mean there is no single truth to the software, except what lags behind in the main branch.
Teaching people to work like this is wrong. We should be teaching them the best options for software development so they can experience this way of working. When they have jobs, they can look back on trunk-based development and bring their employers to this position too. It is hard for them to do that if they don’t have experience with it previously. Go look at all the reasons for using TBD and what others wrote too, to find out more.
Using trunk-based-development (TBD) is right for so many reasons. This is collaborative working. You are working in the open, you are doing small-slices, and feedback is fast too. This is all good. TBD what the DORA team propose too for high quality work.
Go teach your people how to use trunk-based development.
There are lots of guides on TBD as noted above. You just need to start. This is much easier for students too. There is only one branch. Everyone pushes and merges their code to this branch multiple times a day. Look at the work of Paul Hammant for more detail. Thierry de Pauw has also written about the practices of continuous developments, and the evils of branching.
This only works if they talk to each other, and stay in the loop. Talking to others on your team is always good. You find which assumptions are wrong, you develop your shared understanding of the collaboration. This is the way it should be.
This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.
If you’d like to be notified of future posts, then please sign up for more using the adjacent form. When you sign up, then I’ll send you a free copy of the collaboration rules as a PDF from the book. You can also follow me on LinkedIn
The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration. Also available via Kindle.