AFAIK, recovery decision is “internal” to LO. It is based on ancillary files and locks which are deleted when LO terminates normally. When LO is started again, if it finds those files, then it attempts recovery with an auto backup file stored in its user-private directory.
It does not consider any other document. In particular, if you checked out another branch from git, resulting in a different document in your working directory, this difference is not taken into account for recovery decision. The consequence can be wrong document replacement: the recovered document belongs in another branch and it overwrites blindly the checked out one.
On the other side, if you’d like a recovery based on git history, there is no way to trigger one because LO recovery is only a (poor) protection against catastrophic events (power failure, segmentation fault, …), not an easily user-manageable feature (you’re better served with
Save a Copy).
Note also that Git sees LO documents as binary files without any knowledge on their structure and contents. Contrary to text files, Git commits record LO files as a whole (there is no notion of “diff” for them). Replacing a single character by another one, not changing file byte length, nor changing formatting nor any other attribute, will cause the full file to be reentered into the repository on next commit.
As a conclusion, Git and LO are two independent worlds.