Chasing the Trunk Based Development

A source-control branching model, where developers collaborate on code in a single branch called trunk, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after..

Release branch is typically a snapshot from trunk with an optional number of cherry picks that are developed on trunk and then pulled into the branch.

---

Release Branches

In short, to avoid merging mess and suffering because of it the following approaches are quite reasonable.

• Instead of fixing bugs in release brunches. Fix all Bugs in trunk (master)
• You could add release tag on master instead of making the release brunch, fix all "not go" defects right there and then create the release brunch.
• Cherry-pick further bug fixes to release branch if needed (should be rare case).
• Only in rare cases, when there is real production bug, that has to be fixed immediately and there is no way to deploy new trunk release, it makes sense to make a fix for release branch (which is already in production)

So If bug is fixed in master, it's better to deploy master instead of wasting time by porting it back to release or fixing it in release brunch.

Conclusion

The goal of "Trunk based development" is to minimize unnecessary overheads.
Porting things from one branch to another, having many active release branches are waste of time and motivation.

Keep it rational: If you have frequent releases there is no need to producing release branches and constantly back-porting and merging back and forth. It's much more smooth to keep it simple and create the actual release branch lately from trunk, when all "not go" critical defects that have to be in release anyway, are fixed.

---

see Also

• Trunk Based Development
• CSS Tricks - Flexbox
• Redux - Ecosystem
• @angular-redux/store
• Github - Angular CLI