问题
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?
回答1:
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.
来源：https://stackoverflow.com/questions/22471151/git-workflow-for-maintaining-a-derivative-fork