Menu
We've forked an OSS project on GitHub and are adding some custom extensions to it. We'll want to send some of the changes we make back to the original project (bug fixes and the like) but other changes are feature extensions that the original project maintainers aren't interested in at the moment. I'm trying to figure out the best workflow for managing this situation.
I want our master branch to contain the sum of (commits from the original project) + (our bug fixes for contribution) + (our custom extensions). I imagine we'll want a branch-per-feature model so that we can keep bug fixes separate from custom extensions. We can start custom extension branches from our master branch, but I guess we'll also want to maintain a local "origin" branch or something that tracks the original project so that we can start bugfix branches from there that aren't polluted with our custom stuff. Or something.
Can anyone suggest the best way to structure this workflow such that all the various commits go where they're supposed to go and none go where they're not supposed to go?
473
The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository.
A Git workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner. Git workflows encourage developers and DevOps teams to leverage Git effectively and consistently. Git offers a lot of flexibility in how users manage changes.
Topic branches signify that the commits may be overwritten (using a force push) to clean up their structure and be shrunk down to a feature commit. Topic branches are often owned by an individual contributor but can also be a designated space for a team to develop a feature upon.
The Feature Branch Workflow assumes a central repository, and main represents the official project history. Instead of committing directly on their local main branch, developers create a new branch every time they start work on a new feature.
It sounds to me like you have already answered your own question. Create a branch called "vanilla" or something which tracks upstream's master branch, and have a "master" branch which contains your custom extensions. Create branches for each thing you do. For bugfixes, start them off of "vanilla". For your own stuff, start them off of master. Every once in a while, merge vanilla into master. To get the bugfixes into your custom extensions branch, you could merge their branches into master directly, or just wait for upstream to accept your bugfix pull requests, and then the next merge from vanilla to master would contain the bugfixes. This seems like a very normal workflow.
193
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
