title: Git workflow with multiple stable branches, syncing with svn
body: <p>Our project has been <a href="https://stackoverflow.com/questions/2945842/using-git-svn-or-similar-just-to-help-out-with-an-svn-merge">converted</a> from svn to git. Developers are now using <code>git-svn</code>, but would like to 
  move on to harness more of the power under the hood. Wishlist:</p>
  
  <ul>
  <li>powerful branching, e.g topic/feature branches</li>
  <li>isolation between mainline and staging work on releases, sometimes multiple in parallel.</li>
  <li>lean &amp; mean and stable Jenkins-CI setup - minimal maintenance (vs changing job config after each release)</li>
  <li>short iterations, dev team releases to QA every 2 weeks; not necessarily outside</li>
  <li>multiple products (P1..P3) built from the same sources, released independently; with varying pressure</li>
  <li>have more casual, non-git users in the "greater-team"...they are <a href="http://www.youtube.com/watch?v=4XpnKHJAok8#t=8m08s" rel="nofollow noreferrer">S&amp;U</a>:).. but we have to give them svn access to at least 1 branch (trunk). Their contributions is restricted a few dirs, so no much confict risk here.</li>
  </ul>
  
  <p>Would the following strategy work?</p>
  
  <ol>
  <li>develop: the mainline branch where development happens, a'la git-flow</li>
  <li>stable product branches: product1 .. product3. One or more of these will get merges from the main line upon dev release. Seems analogous to 'release start 1.4.3' in git flow-but these would be permanent branches. Releases would be tagged here, then merged back to develop. A this point it would be stable, like master in git-flow, just several of them.</li>
  <li>stop using git-svn directly - pushing/pulling to a mirror instead. The can also use feature branches, if needed</li>
  <li>merge svn/trunk -> develop. Svn would get occasional and isolated check-ins; so planning to automate it by Jenkins job, notifying people if it failed so that can be merged manually</li>
  <li>merge develop->svn/trunk: regularly(eg. daily), in batch mode. This is probably the shakiest part (for newbies at least). Planning something like <a href="https://stackoverflow.com/questions/1464642/git-merge-squash-repeatedly">rebase or some reset wizardy </a> </li>
  <li>CI setup would be straightforward, eg test and dev builds off the mainline, official product builds off their own product branches</li>
  </ol>
  
  <p><a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow noreferrer">Git-Flow</a> is tempting - mainly as it's nicely described and automated. But it does not seem like a perfect match for my case; mainly due to the potentially parallel releases, multiple product lines, and <a href="https://groups.google.com/d/msg/gitflow-users/1Cu8ml4opoQ/G9-g9weN5fsJ" rel="nofollow noreferrer">CI aspects</a>.</p>
  
  <p>Any informed opinions would be greatly appreciated.</p>