My goal as educator since I started at the University of Aberdeen in 2001 is to prepare students for life after graduation. For me, that means providing experiences in the classroom similar to what they’ll encounter later. We could do the easy thing with GitFlow. I think that’s a bad choice, which I only hear open source developers mention, and that’s a special case. I never hear developers who work on commercial products talk about this. I’d rather teach students trunk based development. It provides a better option and experience for them, and is more likely to lead to them having good stories to tell others in job interviews.
As you can see in the graphic above GitFlow on the left, means lots of potential merge conflicts, and a slower learning about the application. Using trunk-based development as shown on the right, everything happens more smoothly.
GitFlow ensures a slow feedback loop
Student projects are always only one team of about six students. This means they can avoid the challenges of multi-team development faced by larger software applications. Six people can easily coordinate their activities to enable trunk-based development.
When computing programmes teach students to write the code, and then submit a pull request this takes too long. Now someone must review the code and approve it to be merged into the main branch. I think GitFlow is a bad option to teach students.
GitFlow ask each person to work in a separate repository branch; even if the person is pairing with another student. Then the code must be merged via a pull request. This means it is being reviewed twice; once when the pair do their work together, and then for the pull request. This slows down integration.
This approach makes it easier for academic staff to determine each person’s direct contribution to the team’s codebase. However, this is possibly not the best way to do that, as it can be gamed by students. This is no different to counting lines of code, and we know how well that works.
GitFlow in Practice
Let’s pause and think about what the GitFlow approach looks like in practice for a moment. If the team meets on Monday to discuss their work for the coming week, and each person has one ticket to do during the week, then this might be done by Wednesday or Thursday depending upon their schedule of classes, homework, part-time jobs, and social and sporting activities . Then each person needs to review another person’s pull request. This might take another day, and it’s now Friday or Saturday.
I’ve made some big assumptions here, which would probably not hold in practice. First, each person can do their work independently, and doesn’t need to coordinate with anyone else with respect to methods, or variable names. Second, each person has submitted perfect code, and no one has their pull request refused, or sent back. Third, there are no merge conflicts as six branches are merged into the main branch.
Discussions about work and how the pieces fit together, or someone makes some changes, then the work takes longer. This is now the next week. This approach ensures slow feedback loops. Not much is accomplished in a term. Students learn about their work slowly when using GitFlow.
Trunk-based development in Practice
The same team using trunk-based development with only one branch of code and maybe a few short-lived temporary branches will probably accomplish more in the same amount of time. The same group meet on Monday and decide how they are doing the work. Even if they all work separately and push to the same repository frequently each session they work, they will discover small merge conflicts, and fix them immediately. As temporary branches merge with the main branch at the end of a day, conflicts resolve there. At weeks end, tasks are done and the new code works. The speed of learning in the team about the application is faster with trunk-based development.
When the team pairs, then there are only three tasks being worked on at once. There is even less potential for merge conflicts. If they are mobbing, then that issue goes away completely.
Yes, software development is not just about how much is done in the time available. I know that most student applications will never be done. These applications they are just like FB and Amazon. They would continually evolve and develop new features, and refine old ones.
The team benefits if they go further in development
What I’m looking for is a team going far enough in one direction to realise they might have made a mistake, and need to refactor their code, or to modify their architecture. I want them to build something larger than what one of them could do on their own. I want them to have a good team collaboration. This only comes when they get over the basics of using agile principles in their development process. As the team do more of this, they learn how to collaborate more effectively, and their development speeds up. This means the team learn more about their application faster.
Trunk-based development is what we should teach our students. These students can learn to work in small chunks, and discuss assumptions upfront with team members in order to smooth collaboration. All of this should look good on a student cv and provide great stories in job interviews.
Go watch and listen to what others say about this too. It’s not just me. Watch and listen to Clare Subery talk about this, and mentions Gee Paw Hill’s ‘Many More Much Smaller Steps‘ approach. Watch and listen to Dave Farley and both Dave and Jez Humble talk about it too, and you’ll find it discussed as a core component of continuous integration at DORA too. Nicole Forsgren, Jez Humble, and Gene Kim also discuss this in the Accelerate book, which summarises early DORA research.
UPDATE 11 December 2023
This post generated a lot of comments on LinkedIn, which pointed me to these other resources on using trunk-based development. If you left comments there, then thank you. That is a great help.
An online version of a book called ‘trunk based development‘ by Paul Hammant spells out lots of reasoning why this is a good choice.
It was also suggested that all of this should happen with ‘git pull –rebase‘ so that any pulls are automatically added to the main history and don’t appear as merges.
A longer piece I found at the time also pointed out by Tim Ottinger on how to make ‘faster and more predicable‘ software development instead of the usual long delays in the ‘normal’ software process, which leads people to use trunk based development.
I also was pointed to a series by Thierry de Pauw on ‘the Evilness of Feature Branching‘, which sets out a number of discussion points.
Another way to stay focused on delivering business value in the team is to use Chris Matts and Kent McDonald’s the ‘Cotswold Way‘ with BDD. This ties in well with Trisha Gee’s perspective too.
And none of this happens without unit tests following the first principles of Tim Ottinger and Jeff Langr.
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.