[erikpukinskis]

Does anyone have experience putting their production branches in a separate repo from their development branches?

GitHub makes it very easy to make a pull request from one repo into another.

This would seem to have a lot of benefits: you can have different branch protection rules in the different repos, different secrets.

Would it be a pain in the ass?

For an open source project you could have an open contribution model, but then only allow core maintainers to have write access in the production repo to trigger a release. Or maybe even make it completely private.

[jhealy]

At a previous employer we did this with our docs repo.

The public docs site was managed and deployed via a private GitHub repository, and we had a public GitHub repo that mirrored it.

The link between them was an action on the private repo that pushed each new man commit to the mirror. Customer PRs on the public mirror would be merged into the private repo, auto synced to the mirror, and GH would mark the public PR as merged when it noticed the PR commits were all on main.

It was a bit of a headache, but worked well enough once stag involved in docs built up some workflow conventions. The driver for the setup was the docs writers want the option to develop pre-release docs discretely, but customer contributions were also valued.