Developers may need to work on multiple open source contributions to the same repository at the same time. Some reasons why this may occur include
The review cycle for open source pull requests may take some time
Making small, well scoped pull requests is often considered a best practice in software engineering
Open source projects may ask that large pull requests be split up so that they are smaller in scope, easier to review, and easier to revert when necessary
Developers may be familiar with stacking changes on top of each other and may want to land a stack of pull requests one after the other
When working outside of Internal Contribution Forks today, developers can make separate branches on their fork for each contribution they want to make. This allows multiple contributions to flow through their fork at a given time. Developers can also make branches on their fork from a source branch other than the default branch, allowing them to make a branch off of an existing branch on their fork. This enables stacked pull requests.
Describe the solution you'd like
Through Internal Contribution Forks, support multiple branches in the public fork that sync to corresponding branches in the private repository for internal contributions. Instead of assuming the default branch of the public and private repositories are used for a contribution, these branches need to be configurable.
Specifically, the following features should be supported or considered
Developers should be able to make a branch through ICF on their private fork corresponding to a given branch on their public fork
ICF should support branch protections or repository rulesets for a configurable set of branches on the private repository
A branch pattern could be configured in ICF for matching branch protections or repository rulesets
ICF would need validation in the UI / API that only protected branches can be synced back to public mirrors
Some form of branch syncing is likely necessary, where ICF should be able to update the public and private repository branches, that correspond to an existing contribution, from the upstream open source repository when another contribution merges
Some open source projects require clean history when contributing and disallow merges in pull requests. Developers may otherwise encounter conflicts and need to recreate their fork and corresponding PR from scratch when their contribution branches become out of sync with the upstream open source repository
Describe alternatives you've considered
Only support concurrent contributions through separate forks. Users will need to manage multiple remotes in their local git config and target the appropriate remotes in git commands, which may get confusing and lead to errors. It is unclear if stacked branches or pull requests would be supported with this model.
Is your feature request related to a problem?
Developers may need to work on multiple open source contributions to the same repository at the same time. Some reasons why this may occur include
When working outside of Internal Contribution Forks today, developers can make separate branches on their fork for each contribution they want to make. This allows multiple contributions to flow through their fork at a given time. Developers can also make branches on their fork from a source branch other than the default branch, allowing them to make a branch off of an existing branch on their fork. This enables stacked pull requests.
Describe the solution you'd like
Through Internal Contribution Forks, support multiple branches in the public fork that sync to corresponding branches in the private repository for internal contributions. Instead of assuming the default branch of the public and private repositories are used for a contribution, these branches need to be configurable.
Specifically, the following features should be supported or considered
Describe alternatives you've considered
Only support concurrent contributions through separate forks. Users will need to manage multiple remotes in their local git config and target the appropriate remotes in git commands, which may get confusing and lead to errors. It is unclear if stacked branches or pull requests would be supported with this model.
Additional context
Here's a helpful blog post on stacked pull requests that walks through the flow for making them. Here are some additional references that may be helpful.