What are best practices for keeping my blog in version control?

In particular, I hear that many people use git to version control a Wordpress blog. (a) (b) (c) (d) (e) (f) (g) (h) (i) (j)

That way if something gets deleted or mangled on the public blog (usually the authorized user, me, making a silly accidental mistake, but potentially some computer cracker trying to push malware to the readers of my blog), it can be easily reverted. Ideally, if the production blog server is destroyed, it should be quick and easy to spin up a new server that is indistinguishable from the pre-destruction old blog server to the typical blog reader.

But a Wordpress blog has a bunch of pieces:

• a SQL database (containing the text I post to the blog)
• a folder containing photos and media I post to the blog
• folders containing the base WordPress software, themes, plugins, etc. that generally I don't expect to ever manually edit, and so in principle I don't need to save because I can simply re-download from upstream, but will change every time there's an update.
• the wp-config.php that (by default) contains the password to the SQL database (and so should not be published in a public gitlab repository).

How many git repositories should I store those pieces in?:

• Should I somehow store the entire website -- blog and SQL database -- in one big monorepo?
• Should I have separate git repos, so that every piece is in some repository or another?
• Should I version-control only things I edit (blog-unique content), and somehow have some tool automatically pull/install/update themes, plugins, etc. available elsewhere?

VersionPress sounds very promising for maintaining a Wordpress blog in a git repository, but as of 2024, VersionPress was still alpha -- not ready for public use. (z)

What's the best practice for posting to a version-controlled Wordpress blog:

• Use the WordPress web editor on the production website server and then somehow pull those changes to a git repo?
• Use the WordPress web editor on some isolated local machine or development server or staging website, and then commit those changes to a git repo and then push to the production server?
• Directly edit the files in the gitlab repo (using the gitlab web text editor), and then "pull" those changes into the production website server?

For a (non-WordPress) simple static website, the answers to those questions seem much simpler:

• Since .html files correspond 1:1 with reader-visible web pages, all those files can be downloaded directly from the website, so there's no secrets -- I might as well stick every .html file for the entire simple static website in a big public gitlab monorepo.
• I can use git in the normal way to allow changes to those files in all 3 locations -- on the simple static website, in the gitlab repo (using the gitlab web text editor), and on a local machine with my favorite text editor -- and then push/pull/merge those changes until all 3 locations are back in sync.