title: Using Git, should a hotfix branch merge with development branch or should it be the other way around?
body: <p>I wonder why in the Pro Git book (Apress 2009), the example in Chapter 3 is:</p>
  
  <ol>
  <li>Everything committed on the <code>master</code> branch now, already pushed to production</li>
  <li>Created an <code>iss53</code> branch for development of a feature, added some temporary changes, and committed.</li>
  <li>A hot fix is required, so switch to <code>master</code> branch and create a <code>hotfix</code> branch</li>
  <li>Fix the bug (such as a typo for the tech support email address), and committed, and push to production</li>
  <li>Switch to <code>master</code> branch and merge with <code>hotfix</code> branch</li>
  <li>(optionally) delete the <code>hotfix</code> branch</li>
  </ol>
  
  <p>Right at this point, I wonder why the book would go to the <code>master</code> branch and do a merge with the <code>iss53</code> branch.  Won't this actually make the master branch in an intermediate state?  What if another hot fix is required, then master is not good for doing a hot fix, and we have to manually choose the commit that is before the merge.  Shouldn't the merge be, going to the <code>iss53</code> branch and merge with the <code>hotfix</code> branch, so that what was wrong will now be incorporated into a future release as well?</p>
  
  <p><strong>Update:</strong> actually, the book had an assumption that the <code>iss53</code> work is complete, and do the last merge.  But what if the work on <code>iss53</code> is not done yet, and we want to merge in the hot fix?</p>