Git workflow for maintaining a derivative fork

Question

Overview

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.

Criteria

We should be able to send pull requests / patches upstream easily
The project needs to track from tagged releases, and may be updated to newer releases as part of our own release workflow.
Needs to have its own tagged releases
Needs to have its own branching structure for a git-flow like development process.

Option 1

Just fork the project on github. Super messy to maintain and get people up to speed on. fails 3,4.

Option 2

Make a new repository, have a project maintainer pull in tagged releases of the upstream codebase as needed. eg something like git fetch upstream; git merge upstream/sometag tagintegrationbranch Not sure how to easily push fixes upstream in this model. Kind of fails 1.

Option 3

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.

Option ?

Something I have not considered?

Has anyone tried any of these methods for a significant period of time? If so, what kind of non-obvious challenges did you have? What branch naming scheme did you use (so that myself and others can possibly use it to create/follow a pseudo-standard naming system for this process)? — Jeff Hykin, May 31 '20 at 03:09

score 6 · Answer 1 · edited May 23 '17 at 12:10

Option 3 seems to represent to clearest separation of workflow between the two projects:

one with occasional contribution back to the original project, with pull requests
one with entirely new branches and code for the new application

To facilitate the merges, I would recommend using hierarchical branch names in your repo, in order to clearly separate:

branches for your project development (classic names, no need for a '/' in them)
branches from the upstream/original repo (all prefixed with a name representing a branch from the original repo, like 'original/dev', for you to cherry-pick from or to)
Those branches are already in their remotes/upstream namespace, but if you want to push back new commits, you need to create a local branch, and my point is: the name of that local branch should have a '/' in it, in order to clearly differentiate it with other regular branches for your project.