Thank you for the thoughtful reply. I've always kind of struggled with the one repo per logical project idea. The organization I work for has many different research programs, one of which I manage. So from the organizations perspective my research program is one logical project so we get one repo.
Obviously we have many different projects within our program however. We might be writing several papers that each require a specific data analysis, meanwhile I may put together some slides in using .Rmd and isoslides. I want the code for all these to be public. Are those all what you would consider separate logical projects?
And then there's the question of what to do with all those random bits of code you write, for example, to produce a sub-sample list of samples to send off for analysis. You want to record how you came to that decision somewhere (in the form of a script) but it doesn't really belong to a project. Perhaps this is where simply putting these files in Google Drive in a 'sub-sample lists' folder is sufficient.
I understand now that merge conflicts are the reason for using git. My understanding is certainly still developing, and what I think I was experiencing wasn't precisely merge conflicts per se but rather whenever I did a pull, I would get an error message because he or I had removed some files from the giant monorepo, or changed files that weren't text files as you mention. Also, we were experiencing many working directory issues, luckily my computer wasn't burned down, but I should be safe now I've heard of the here() package.
I think there is some utopian hybrid of using Google Drive for certain things (Sheets, Docs, Slides, random R scripts) and GitHUB for others (logical projects, collaborative projects, peer-reviewed analyses). Getting closer to the ultimate workflow, but certainly still developing...