title: git - rebase ruins merge
body: <p>I had two branches both independent.  I worked on them at various points over a month. I went to merge one branch (let's call it <code>apple</code>) into the other (let's call it <code>orange</code>) by checking out orange and doing <code>git merge --no-ff apple</code> and everything went fine. In gitk I could clearly see the branches each had their own history and it was merged together in a merge commit on orange.  </p>
  
  <p>Later I realize that a commit in orange is incorrect, there is a mistake in the build process, and I must edit that early commit on orange. I use <code>git rebase -i HEAD~19</code>, choose the commit and change <code>pick</code> to <code>edit</code>. So I edit the commit and everything is fine, and I finish the rebase. I go back into gitk and all the history of the two branches is one linear history on orange.  </p>
  
  <p>So did I screw something up or is this the way it's supposed to be? I used git reflog to go back to when I did the merge, then I did another reset hard to go back to right before the merge on orange, then I did the rebase and fixed that commit, then after that I did the merge. Now everything looks the way I'd expect where the commits from the branches aren't interlaced together.  </p>
  
  <p>For future reference can someone tell me how I can rebase commits on a branch where I've merged in another branch, without ending up with interlaced commits (linear history)?  </p>
  
  <p>If my terminology isn't correct feel free to edit this. Thanks again</p>