Concurrent contributions through a single private fork

[wrslatz]

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

• 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.

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.

• https://benjamincongdon.me/blog/2022/07/17/In-Praise-of-Stacked-PRs/
• https://www.michaelagreiler.com/stacked-pull-requests/