I believe git was originally designed to share commits via email.

Here is one of the top hits searching "git email patch"

https://thoughtbot.com/blog/send-a-patch-to-someone-using-gi...

They can always tar up their repo and send it over. You then unpack it on your end, then set it as a remote, pushing/pulling from it as you see fit. Admittedly, not the greatest workflow, but it doesn't require any new tools if you are already familiar with remotes.

As another alternative, git-format-patch/git-apply or git-bundle may be a quicker way of shipping changes around.

You don't need write access to a remote for that remote to be useful. Two or more people can collaborate using public repos that others may fetch from but not push to. Then, in lieu of github PRs, you request other people pull from you with email or however you like.

If you need access control without VPNs or whatnot (or if you simply want something closer to the github workflow), there are other services similar to github that can almost certainly provide what you need, such as gitlab.

> "Also, the additional effort to manage multiple remotes is entirely nontrivial."

With practice, I'd say it asymptotically approaches trivial.

1. Send a series of patches in an email.

2. Send a branch in whatever file exchange service you use. (Also formatted as patch series)

3. Setup ad-hoc vpn (zerotier?) and setup remote via SSH.

4. Push the branch into a private repository on a different service (private gitlab?)

5. Spin up a free t2.micro on AWS and push the branch there.

There are lots of options.