title: Robust workflow for catching up with a master branch?
body: <p>Let's say I am working on a non-trivial feature branch that is following a "master" branch of a project with quite a bit of activity. This routinely leaves me in a situation that for sake of saneness, I have to fall a bit behind the "head" in order to figure out how to make something work.</p>
  
  <p>This often leads to a situation where my branch is a few thousand commits behind the master branch - with all the fun things that entails, such as relevant modules getting refactored or similar. Once I decide to start "catching up" this leaves me with with a tricky task: A monolithic merge is out of question, as:</p>
  
  <ol>
  <li><p>It's practically impossible to consider all "my" changes multiplied by all "master" changes at the same time. The few times I tried this, I made so many mistakes that I eventually had to back out.</p></li>
  <li><p>The resulting merge would be so gigantic that all the magic hidden within it would be quite a documentation nightmare.</p></li>
  </ol>
  
  <p>As a result, the approach I have ended up with is doing "staged" merges: Instead of merging with master directly, selectively merging with "interesting" points in master's history. This would typically be commits concerning modules that likely have "tricky" conflicts. The great advantage of this is that I have actual buildable intermediate points that I can reason about and test, therefore making the whole process much more manageable.</p>
  
  <p>Yet this approach seems to have downsides... Namely, if there's a mistake in a merge that I only notice later on. I tried using <code>git rebase -i -p</code> in order to squash fixes into the history, but found out the hard way that this doesn't seem to be the kind of usage people behind it had envisioned. To be specific</p>
  
  <ul>
  <li><p>inserting changes between merges seems to cause the rebase process to bail out with more or less complicated conflicts, and</p></li>
  <li><p>squashing a regular commit into a merge commit seems to make the new commit a non-merge, losing the reference to the merged commit</p></li>
  </ul>
  
  <p>Now I'm halfway towards working around all this using some more or less fancy shell scripting, but I am seriously wondering whether I have just missed some piece of Git functionality that could help me with dealing with this situation. Best idea I could come up with so far is using rerere to redo all the merges manually.</p>