Git user here. Being able to recover older versions of your DEVONthink databases (or any databases) is a sensible idea. IMHO, the use of git is not the best approach, and I’ll try to summarize why.
The purpose of git is to let you store, track, and retrieve versions of files. However, it’s optimized for text files, which it stores not by keeping full copies of every version but by storing the differences from one version to the next. This is easy to do when a file is stored on disk as plain text (there are known methods for doing that), but as you yourself alluded to, it’s generally not possible to do if the file is a binary object such as a database or a movie file. Yes, non-text files can be stored in git, but then git has to store the entire file (albeit compressed) every time you save a version. The consequence is that space usage goes up dramatically if you edit/annotate a lot of PDFs, images, and other non-text files in your database.
Using git also requires manual action; it is not something that will automatically save a version very time you make a change in some other software like DEVONthink. You could arrange a scheme to do that (or DEVONthink could incorporate it), but at minimum, that’s going to lead to a lot of very small changes being saved all the time, compounding the problem described above. Could you take snapshots periodically, say every hour? That might help, but there remains another issue: database consistency.
A DEVONthink “database” actually contains individual files (the assets like the PDFs and other files), plus some kind of core database index (containing the metadata, tags, and other aspects that are not stored in the files). I don’t know the details of DEVONthink’s implementation, but that index is probably a binary object on disk. For reasons discussed above, git would have to save the whole index file when it takes a snapshot. But software systems like DEVONthink don’t save their state to disk constantly: doing so would be prohibitive performance-wise. Instead, some dynamic state is in computer memory, and only at certain points in time does that memory content get saved to disk. The issue is that no changes can take place to the index file on disk while a snapshot is being saved in git, because you need the disk contents to be in a consistent state at the time of the save operation. (I think this is what @cgrunenberg was referring to when he said the database would have to be closed before taking a snapshot.) The practical implication is that either DEVONthink flushes everything to disk and becomes temporarily unresponsive while the git save takes place, or it keeps running for a short time without saving changes to disk, which brings the risk of data corruption if something bad happens (e.g., power goes out) at the wrong moment.
The longer you wait between snapshots, the more accumulated changes to both the database index and some subset of individual file assets there will be since the last snapshot was taken. The more changes there are, the more work git has to do to save a snapshot, and thus, the longer the save operation will take. The longer it takes, the more irritated the user or the greater the risk elsewhere.
There are database systems that work around that – after all, database backups is not a new concept, and maybe DEVONthink could use such a system. But, given all the issues above (and probably many I didn’t think of), you can see that git per se is just a good match for this purpose.