Edit: I can see where your solution has an advantage. When one accepts contributions, all of that can be automated with web hooks via github. Still, having to run lambda/similar for this is a bit heavy weight.
Edit 2: Considering that for a release, I would opt in for release from a tag or explicit commit, that would be a non issue. Pull when needed, for redundancy, use another, self hosted bare repo. Push there in case of github down.
Wouldn't replacing the github hook with a git-hooks script incrementally improve the solution as it currently exists?
Then, combine that with a git-hook script that designate all non-release branches push to team's Keybase repo as well? Maybe including a custom prefix in the branch name to avoid need for conflict resolution?
I'm also thinking that it would be easier to use git-hooks to push to AWS CodeCommit (in a random region that GitHub is unlikely to use) paired with CloudWatch events to invoke service backup to Keybase
Of course, ideally it would be a Terraform (or similar open source stack) script so it's not dependent on AWS as a vendor... I have experienced the real pains of vendor lock-in, even with cross-region there is opportunity to improve robustness
Edit: I can see where your solution has an advantage. When one accepts contributions, all of that can be automated with web hooks via github. Still, having to run lambda/similar for this is a bit heavy weight.
Edit 2: Considering that for a release, I would opt in for release from a tag or explicit commit, that would be a non issue. Pull when needed, for redundancy, use another, self hosted bare repo. Push there in case of github down.