Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.
I think I have this resolved over here, using a trick I was using with 2.2.5:
Go to your project's root; make a file called .gitattributes (note, not .gitattributes.txt, just the extension).
Open the file with Notepad++, enter:
What this is supposed to do (if I read Git's documentation correctly) is force Git to treat .yyp, .yy, and .gml files as text files, but exclude .png. I think the * -text excludes sound files (which, strangely, have no file extension). With 2.2.5, this significantly impacted laggy behavior when using Github (especially epic-length wait-times to commit something). I'm really not sure why source-control is still having all these issues in 2.3; I reported a lot of these issues in detail months ago.
Interesting. Are you using GMS on a Mac or some other platform where CLRF isn't normative for line-ends?
And... are you working with others, or just using Git for backup? I wasn't able to make Git work reliably by itself when working with remote help; we all had to use GMS's solution, with the above caveats, or we had severe problems with Views borking merges.
Given that Views are "internal project configuration files" and also don't like merges, rather than being a core part of the end product like a YYP defining an Object, I haven't got the foggiest idea why GMS doesn't have them stored outside the projects, but that's a side issue.
I'd love to know why "diff" in .gitatttributes works; I don't understand what it does, and the Git documentation on it doesn't help, lol. I'd have thought having a diff tool installed in GMS took care of flagging / fixing anything that needed diff during a merge. But I certainly don't know everything about how Git works, just that the above worked for me, lol.