Avoid Git merge hell with trunk-based development
Regardless of whether I was working as part of a team or individually, I used to create a new branch for every change. I'd do the work and merge the feature branch back into the mainline branch - usually either main or develop.
When working on a team, conflicts are common that prevent different changes from being merged, and they're more likely the more time it's been since the last merge and how large the change is.
Once, when demoing some in-progress work to a freelance client, I needed to switch branches as the changes were on different feature branches. Doing so broke my local environment and derailed the demo.
Trunk-based development
These days, I advocate for and prefer to use trunk-based development. Instead of committing changes to feature branches, they are made directly to the mainline branch.
As there are no feature branches, there are no merge conflicts when merging into mainline.
Although there can still be conflicts when pulling remote changes, trunk-based development pairs nicely with continuous integration - when everyone works in small commits and pushes changes at least once daily. This makes conflicts less likely but also smaller and easier to resolve, and because everyone's changes are not hidden on feature branches, you know they will integrate and work together.
It also stops me from breaking my environment during client demos!
- Oliver
