(This is as non-technical as possible so be warned it doesn’t use the right terminology per se)
Git is confusing at first. Basically your code is on a Git branch, such as “master”. Over time you might create other branches.
When someone wants to work on the project you “clone” the Git, then “checkout”, then work on it.
So at this stage each person will have a “copy” of the whole project.
As each person now changes stuff each person will have something “different” from the master branch.
That’s when you “push” your changes to the master branch, and then you “pull” your changes from the master branch.
This is now the harder part because now you have to make sure you want to have the right stuff added to the branch and you want to make sure people are working on the latest code.
So then that’s the push-pull management, branching, etc. which gets more hardcore. That’s when things like pull requests become important because there should be someone in charge of what gets added to the branch. For example, team members shouldn’t be able to “force-push” code to the branch.
Well that’s my layperson’s overview, as a layperson.
Don’t think you’re stupid or anything, Git is very, very powerful and it just takes time to understand how to “think” in a Git way, as opposed to a traditional SVN-checkout type thing. There’s also Perforce which I hear is good but haven’t tried.
From what I have tried with Git as I mention once you understand how to think like a Git (sounds horrible, I know) it makes more sense.
Finally for projects with large files there’s Git LFS or use Git ignore to only synchronise important parts of the project and use a separate repository eg. Dropbox(?) or Mega(?) for common, in-progress, etc. large assets. You don’t want to be cloning, pushing, pulling with huge files, that’s why Git is best suited to source code and not binaries or massive assets unless you use Git LFS (Github LFS?).
Good luck! 
Faster this way!