The big dilemma as you move to SSG: public or private repo?
If public, people can PRs fix things, but everything is public: no real drafts, no pwd-protected pages.
This is one instance of a more general problem, where you really need a public repo with only a few private files.
Other instances of the same problem:
a) Private config files
b) A class website that also wants to have solutions for course staff
I can think of several solutions.
From the version control platform side:
a) a .gitprivate file: same syntax as .gitignore, but instead of ignoring, it keeps files private
b) Private branches
From the serverless platform side:
Ability to combine two repos to the same website, then people can use one public and one private. Both would be deployed separately, then file subtrees merged recursively. If there are conflicts, one of the two (user choice which one) would take precedence.
Yes, the latter is a substantially more complex solution, which is why it would really be great if this was solved on the @github side.
And to stop the 'splainers, yes I know about environment variables. They are an awkward, non-portable solution, and only work for very simple data like API keys.
I agree, we should get that better. But I think marking individual files as private may be not enough.
Best security strategies are the ones that make really hard to make mistakes. Mixing in the same place public and private items makes it very easy. And we do that too much, usually because frameworks and tooling make it hard for us to do it otherwise.
Public and secret files should be in totally separated folders and repos. There are already too much passwords and private tokens in public repos. Even better, secrets shouldn't even be on files. Why don't we have password managers for web apps?
