title: Force git to make no-op commits during rebase
body: <p>So I've jumped through a lot of hoops to make the fork/rebase/pull-request git workflow palatable to developers on my team who fear version control and the command line.</p>
  
  <p>In adding a rebase article to our development wiki, I just got to the point where I say "Do <code>git rebase</code>.  If there are any merge conflicts, fix them.  Then do a <code>git add</code>.  Then do <code>git rebase --continue</code>."</p>
  
  <p>But in working through the example and taking the screenshots, I was reminded that if there's a merge conflict, and I resolve it in favor of the upstream branch, doing a <code>git rebase --continue</code> in fact refuses to continue and gives an error:</p>
  
  <pre><code>No changes - did you forget to use 'git add'?
  If there is nothing left to stage, chances are that something else
  already introduced the same changes; you might want to skip this patch.
  </code></pre>
  
  <p>There's an excellent discussion of the technical details here: <a href="https://stackoverflow.com/questions/4033009/git-rebase-conflicts-keep-blocking-progress">Git rebase: conflicts keep blocking progress</a></p>
  
  <p>But what I'd like is to make this behavior <em>stop</em>.</p>
  
  <p>I assume there's a good design reason why this happens (probably related to rebase just using the normal commit machinery, where this behavior likely makes sense) but in this situation it's confusing and unintuitive and makes the conflict logic: "Fix the conflict.  If your fix looks exactly like the upstream branch, do a <code>git rebase --skip</code>.  In all other cases, do a <code>git rebase --continue</code>."</p>
  
  <p>Is there a way to squelch this behavior, either with a flag to rebase or in a version-controlled configuration file (so I don't have to set it up on each dev's computer or provide instructions for doing so)?</p>