Are your images original work or can they be recovered (guaranteed?) from elsewhere? Are they needed to ship a software unit built from source?
If they are original, they need backing up. Put them in your revision control, if they never change, the space penalty is the same as a backup, and they are where you need them.
Can they be edited to change the appearance of the software, accidentally or intentionally? Yes - then they MUST be revision controlled somehow, why use another way when you have a perfect solution already. Why introduce "copy and rename" version control from the dark ages?
I have seen an entire project's original artwork go "poof" when the graphics designer's MacBook hard drive died, all because someone, with infinite wisdom, decided that "binaries don't belong in rev control", and graphics designers (at least this one) don't tend to be good with backups.
Same applies to any and all binary files that fit the above criteria.
The only reason not to is disk space. I am afraid at $100/terabyte, that excuse is wearing a bit thin.
Look at how facebook does it with their own app, called phabricator: http://phabricator.org/
They basically commit on a per issue basis, and for each issue, the code is shown, which is to be reviewed by someone. The code doesn't go into their main repository until the reviewer said it's ok to do so.
I guess it makes it more fun.
Also, perhaps a code should be assigned to two people: one who does it and one who reviews it.
Albeit perhaps your teammates don't believe in this review thingy.
Personally, in lack of reviewers, I used unit tests for lower-level functions and "the janitor test" for all the rest: the janitor test is called that way, because even the janitor should be able to understand your code.
I usually removed some minor parts, like block / function scope brackets, visibility notations, sometimes even types, and showed it to managers, domain experts, mates, whoever requested the code: "is this what you want?"
Also, going there personally and not leaving until reviewing is done helps.
Or, in case you're not fine with the team, or they're not fine with you, you know, "if you can' change the company, change company"...
Best Answer
Since it's not clear from your question, I just want to point out that a gatekeeper workflow is by no means required with git. It's popular with open source projects because of the large number of untrusted contributors, but doesn't make as much sense within an organization. You have the option to give everyone push access if you want.
What people are neglecting in this analysis is that good programmers spend a lot of time dealing with other programmers' broken code anyway. If everyone has push access, then the build will get broken, and the best programmers tend to be the ones frequently integrating and tracking down the culprits when things break.
The thing about everyone having push access is that when something breaks, everyone who pulls gets a broken build until the offending commit is reverted or fixed. With a gatekeeper workflow, only the gatekeeper is affected. In other words, you are affecting only one of your best programmers instead of all of them.
It might turn out that your code quality is fairly high and the cost-benefit ratio of a gatekeeper is still not worth it, but don't neglect the familiar costs. Just because you are accustomed to that productivity loss doesn't mean it isn't incurred.
Also, don't forget to explore hybrid options. It's very easy with git to set up a repository that anyone can push to, then have a gatekeeper like a senior developer, tester, or even an automated continuous integration server decide if and when a change makes it into a second, more stable repository. That way you can get the best of both worlds.