title: Git workflow for maintaining a derivative fork
body: <h2>Overview</h2>
  
  <p>I have a project that is a customisation of an existing FOSS product. Its getting to the point where we're maintaining a long-term fork rather than applying new plugins and the like. I'd like some input on what the sanest workflow for maintaining this project might be.</p>
  
  <h2>Criteria</h2>
  
  <ol>
  <li>We should be able to send pull requests / patches upstream easily</li>
  <li>The project needs to track from tagged releases, and may be updated to newer releases as part of our own release workflow.</li>
  <li>Needs to have its own tagged releases</li>
  <li>Needs to have its own branching structure for a git-flow like development process.</li>
  </ol>
  
  <h2>Option 1</h2>
  
  <p>Just fork the project on github. Super messy to maintain and get people up to speed on. fails 3,4.</p>
  
  <h2>Option 2</h2>
  
  <p>Make a new repository, have a project maintainer pull in tagged releases of the upstream codebase as needed. eg something like <code>git fetch upstream; git merge upstream/sometag tagintegrationbranch</code> Not sure how to easily push fixes upstream in this model. Kind of fails 1.</p>
  
  <h2>Option 3</h2>
  
  <p>Fork the upstream project, use that as the upstream like in Option 2. Used as an aide to the PR system. Will probably have to do cherry-picks or some similar micromanagement to push code back up this workflow depending on how well feature/bug branches are managed, but should be fairly clean. Seems to satisfy most criteria.</p>
  
  <h2>Option ?</h2>
  
  <p>Something I have not considered?</p>