Don’t you know trunk-based development is where it’s at?
Source control is something I have had a love-hate relationship with for many years. Initially, I worked on some small projects without it.
Then I began to work with larger teams and source control was necessary. It was the late 90s and we used Visual Source Safe. It was a clumsy solution at best.
Later I worked with CVS and then Subversion. The idea of these two is quite similar. The centralized repository was something I could understand. Although with Git I struggled to understand.
Versioning
As the repositories have changed so has the versioning model. There have been a lot of arguments about branching and features. Developers enjoy pedantic discussions about these things.
Feature branching
Feature branching has been common for teams for a while. Here is how Martin Fowler describes it:
A feature branch is a source code branching pattern where a developer opens a branch when she starts working on a new feature. She does all the work on the feature on this branch and integrates the changes with the rest of the team when the feature is done.
This approach has some pros and cons. Allowing someone to work on a branch without impacting other developments can be helpful. On the downside, it takes time to get code reviewed and can lead to merge issues.
Git Flow
The Git Flow model uses the feature branching model to complete feature work. Then it merges it back to a main branch. In this scenario, the main branch is a long-standing branch that has multiple features merged into it.
Similar to feature branching Git Flow merges take time and a lot of eyes to ensure nothing is lost. I have seen changes half merged as the code was overwritten in the process.
Trunk based
Moving to trunk-based development has many benefits. One big one that Denis Kranjcec points out is the ability to react quickly to updates from vulnerabilities.
Yes, there are common reservations about this approach. For example, what about pushing incomplete features? This can be alleviated by reviews after merging and feature flags.
The bit change here is in the mindset shift. Code must be created with Test Driven Development and pairing or mobbing. From a more individual approach to team development.
Git-Flow vs Trunk based
These last two approaches are quite popular today. Of course, you are going to ask me which one to use. That is a great question. Luckily for us, Konrad Gadzinowski has answered it here.
The short answer is it depends. I was hoping for something easy too. Konrad points out that if your team has mostly senior developers trunk-based approach will work.
On the other hand, if you have mostly junior developers the Git flow model can be a better solution. Another important question are speed of implementation. Teams that iterate quickly should use trunk-based models.
In conclusion, trunk-based development can work for mature teams. The Git Flow can work for lesser experienced teams. As well as teams that don’t change code as often. Like anything your mileage may vary. Experiment and pick a solution that works best for you.