title: Git: regular merge/rebase of long-living bugfix branches to master
body: <h2>Context</h2>
  
  <p>We use several git repositories with the same workflow, involving two branches, and are wondering how best to "synchronize" commits from one to the other.</p>
  
  <p>Put simply, our git repositories contain:</p>
  
  <ul>
  <li>Long living branches</li>
  <li>Two branches:
  <ul>
  <li>master (branch for ongoing development)</li>
  <li>1.0 (branch for bugfixes only, to maintain a stable version)</li>
  </ul></li>
  <li>Both branches are both regularly pushed to a public repo</li>
  <li>Sometimes, ongoing development and bugfixes affect the same lines in the same files, so conflicts occur when merging/rebasing/etc.</li>
  </ul>
  
  <p>We also have some less common conditions:</p>
  
  <ul>
  <li>Unusual ratio: diffs of bugfixes (on 1.0 branch) are much bigger than those from ongoing development (on master branch).</li>
  <li>Sometimes, commits from the 1.0 branch are cherry-picked to the master branch ("urgent" bugfixes needed both for stable releases and for development)</li>
  </ul>
  
  <p>We could illustrate this as follows (commit <code>5'</code> is a cherry-pick of commit <code>5</code> from the 1.0 branch):</p>
  
  <blockquote>
  <pre><code>-1--2-3--5'--7-- (master)
       \
        4--5---6-- (1.0)
  </code></pre>
  </blockquote>
  
  <h2>Aim</h2>
  
  <p>Every so often, we need to make sure all bugfixes on the 1.0 branch are available on the master branch.</p>
  
  <p>When doing this, our needs are:</p>
  
  <ul>
  <li>The 1.0 branch must not be changed (no commits from master go to 1.0 branch)</li>
  <li>Master needs to remain compatible with origin/master, so that we can push to a remote repo. This basically means avoiding rewriting master's history (unless there's a magic way to push this we don't know about!)</li>
  <li>We don't want to lose the commit history: we need to be able to see whether a commit from the 1.0 branch has been applied to the master branch.</li>
  <li>We'd rather not have to manually resolve conflicts arising from previous cherry-picks, I think git should be able to work this out by itself (as indicated in the man pages).</li>
  <li>In the future, we'll reach a similar situation again, and need to resolve it the same way, but don't want to have to remember what resolutions to use for the commits 4 and 6 that we've already sorted out once.</li>
  </ul>
  
  <p>So, an illustration of the situation we're aiming for is:</p>
  
  <blockquote>
  <pre><code>-1--2-3--5'--7--4'--6'-- (master)
       \
        4--5---6-- (1.0)
  </code></pre>
  </blockquote>
  
  <h2>What we've tried</h2>
  
  <ul>
  <li>Using a copy of the 1.0 branch, and rebasing it onto master:
  <ul>
  <li>Seems to work</li>
  <li>But if we do the same operation again in the future, we have to review new commits AND old ones</li>
  </ul></li>
  <li>Rebasing master onto the 1.0 branch
  <ul>
  <li>Works in a local repo</li>
  <li>But can't be pushed to remote, as this would be rewriting origin/master</li>
  </ul></li>
  <li>Merging 1.0 branch into master
  <ul>
  <li>All conflict resolution ends up in ONE single commit, so the history doesn't show the actual modifications previous commits required</li>
  <li>Ideally, we would need a "git merge --interactive", similar to "git rebase --interactive": merge branches but interactively choose which commits to include or not, as we go</li>
  </ul></li>
  </ul>
  
  <h2>The question</h2>
  
  <p>It seems to us that this is probably a pretty typical use case for git, or for anyone maintaining and developing software in a public git repo, anyway.</p>
  
  <p>How would you go about this?</p>
  
  <p>Thanks!</p>