What are the pros and cons of using a trunk-based Vs feature-based workflow in Git? : <p>I pretty much like the idea of the feature-based workflow in Git: using feature branches to support parallel development.</p>

<p>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 &amp; 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. </p>

<p>I find the aforementioned workflow fine. However, in some internet posts, they advocate for a  "trunk-based development" (e.g.  <a href="https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/" rel="noreferrer">1</a>, <a href="http://paulhammant.com/2013/04/05/what-is-trunk-based-development/" rel="noreferrer">2</a>).</p>

<p>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). </p>

<p>I was wondering which advantages this model would carry over the feature-based model. I have several doubts with the trunk-based model:</p>

<ol>
<li><p>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)?</p></li>
<li><p>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?</p></li>
<li><p>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?</p></li>
<li>Overall, which benefits can carry the trunk-based compared to the
    feature-based workflow?</li>
</ol>

<p>Thanks :-)</p>
