That said, there are some serious problems to using screen diffing. First, it requires manual testing. You will need a pair of human eyes to determine if a change is breaking or not. Second, there are a lot of false positives that make testing slow. When a few pixels are moved on the page, is it okay? Third, there's a _LOT_ of data you will need to look at before you can be confident about the diffs. You will need to do a screen shot for each page for each resolution for each git commit.
The signal to noise ratio is very low for screen diffing. You would be MUCH better served by using (in the case of web apps) Selenium web driver tests to make sure your page works. As a bonus, with automated tests you can use git bisect to quickly find the offending commit!
It's worth noting that this is also something Selenium does, so you could just add the screenshots from that layer of integration testing to version control and require these tests be done at each commit or merge. To justinjlynn's point, you should have a separate repo for this due to some of Git's struggles with extremely large blobs.
Just a helpful hint, in terms of authorship:
"Cut out all those exclamation points. An exclamation point is like laughing at your own jokes." —F. Scott Fitzgerald
Alternatively, it would be cool if you could keep a repo with copies of every working version of the end software product such as abinary file or live website. e.g. chrome checkout <commit-hash>