Git Rebase repeats conflicts from last Rebase
<p>Are there any common git usage mistakes or in general any reasons at all why a rebase would repeat the conflicts from the previous rebase if those conflicts had all been resolved in the previous rebase?<br>
Furthermore, does rebase have a preference over how the conflict was resolved? e.g. does rebase want a strict choice between the two possible code snippets in the usual git conflict brackets within the code or is it just as fare to it to remove everything between the <code>&gt;&gt;&gt;</code>,<code>&lt;&lt;&lt;</code>?  I'm curious if removing both code choices to resolve the conflict will affect rebase's ability to resolve later conflicts properly.</p>

<p>Further elaboration:
I have a <code>master</code> branch and a <code>dev</code> branch.  The <code>dev</code> branch I've been working on the side for some time so the number of differing commits has grown quite large, in the 100s (I know...should <code>dev</code> into <code>master</code> more often).  <code>dev</code> branch itself has had several smaller feature branches cut from it and then merged back in, only ever having been cut, rebased, merged with <code>dev</code> branch and never <code>master</code> branch (that I can remember).  I rebased <code>dev</code> branch onto <code>master</code> branch 1 week ago.  I have since made a few more changes on <code>dev</code> branch and would like to rebase on <code>master</code> once again so I can prepare for a merge.  There has been a very small change to <code>master</code> branch in that 1 week window as well but the code files don't overlap.  However, when rebasing <code>dev</code> onto <code>master</code> I'm seeing the same set of conflicts being raised by git when I attempt the current rebase as compared to when I rebased one week ago. </p>

<p>Thanks!</p>