title: When to use the '--no-ff' merge option in Git
body: <p><a href="http://nvie.com/posts/a-successful-git-branching-model/">A Successful Git Branching Model</a> recommends to use <code>--no-ff</code> when merging branches:</p>
  
  <blockquote>
    <p>The <code>--no-ff</code> flag causes the merge to always create a new commit
    object, even if the merge could be performed with a fast-forward. This
    avoids losing information about the historical existence of a feature
    branch and groups together all commits that together added the
    feature. […]</p>
    
    <p>Yes, it will create a few more (empty) commit objects, but the gain is
    much bigger that that cost. Unfortunately, I have not found a way to
    make <code>--no-ff</code> the default behavior of git merge yet, but it really
    should be.</p>
  </blockquote>
  
  <p><a href="https://sandofsky.com/blog/git-workflow.html">Understanding the Git Workflow</a>, however, recommends <em>not</em> to use <code>--no-ff</code>:</p>
  
  <blockquote>
    <p>So you add a new rule: “When you merge in your feature branch, use
    <code>–-no-ff</code> to force a new commit.” This gets the job done, and you move
    on. […]</p>
    
    <p>The <code>--no-ff</code> band-aid, broken <a href="https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html"><code>bisect</code></a>, and <a href="https://www.kernel.org/pub/software/scm/git/docs/git-blame.html"><code>blame</code></a> mysteries are all
    symptoms that you’re using a screwdriver as a hammer. […]</p>
  </blockquote>
  
  <p>Both approaches seem reasonable for difference scenarios, but what is considered "good practice?"</p>
  
  <p>When do you use <code>--no-ff</code>, when do you not, why?</p>