Menu
Trunk-based development is far more simplified since it focuses on the main branch as the source of fixes and releases. In trunk-based development the main branch is assumed to always be stable, without issues, and ready to deploy.
One key benefit of the trunk-based approach is that it reduces the complexity of merging events and keeps code current by having fewer development lines and by doing small and frequent merges.
Build your strategy from these three concepts: Use feature branches for all new features and bug fixes. Merge feature branches into the main branch using pull requests. Keep a high quality, up-to-date main branch.
Mainline is diametrically opposite to Trunk-Based Development - do not do this. Mainline is a branching model that was promoted for ClearCase implementations. It is the principal branching model that Trunk-Based Development opposes.
I pretty much like the idea of the feature-based workflow in Git: using feature branches to support parallel development.
In a feature-based workflow, I would develop my tasks in a feature branch (off master), and I would rebase often from master to avoid potential conflicts. If collaborative, I will push/pull the feature branch to the remote. When ready to integrate to master, I open a pull-request from my feature branch to master, so that the pull-requests is reviewed by peers & automatically assessed to know if the pull-request (the merge of my feature branch into master) passes the build and unit-tests. If the pull-request is "green" then my feature branch is automatically merged to master.
I find the aforementioned workflow fine. However, in some internet posts, they advocate for a "trunk-based development" (e.g. 1, 2).
As far as I am concerned, trunk-based development does not encourage developing into separate feature branches but all developers develop into master. This model, encourages that developers integrate daily (Martin Fowler's CI practice) to the master to avoid conflicts (in contrast, what I would do is to rebase my feature branch on master).
I was wondering which advantages this model would carry over the feature-based model. I have several doubts with the trunk-based model:
How would code-review be done? In feature-based model is easy: into the feature branch. In the trunk-based model, since all the commits are published in master, how can I make them reviewed? In fact, if I resolve conflicts when merging into master, wouldn't this commits appear as to be reviewed (i wouldn't like that)?
How would two developers collaborate on the same feature? In the feature-based model, both would work on the feature branch. In the trunk-based model, all developers would be collaborating in "all the features" (somehow). Right?
I believe, the trunk based model was "created" to avoid the problem of long-lived feature branches are their potential conflict hell when merging it to the mainline. However, if feature branches are short-lived, and if they are often rebased from the mainline, what is the issue then?
Thanks :-)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With