I am a deals attorney and a programmer. I'd caution against conflating comparison tools like "diff" with Git and revision control more generally.
Lawyers call change sets "redlines" rather than "diffs". Their use in the profession long predates modern computing. Word has a serviceable built-in diff tool called "Compare Documents", and many law firms license superior document comparison software. Prose diff is hard, and specialized law tools far surpass diff, wdiff, GitHub prose diff, &c. in areas like move detection and treatment of punctuation.
Source code revision control systems are built for, and conducive to, modes of collaboration that only occasionally resemble legal practice. In the main, lawyers trade "patches" with commentary via e-mail, which is still the practice of some important open-source projects, like Git itself. (For a nice comparison of this workflow to "GitHub flow": http://zachholman.com/posts/git-commit-history/ . See also git-send-email and git-format-patch.) A developer might be tempted to squash commits to make a "pretty" patch. In an adversarial negotiation, hiding incremental revision history is essential for maintaining confidentiality and information advantage. If you're going to squash, anonymize, remove timestamps, &c. every time, Git is overhead and potentially dangerous. Git's architecture does not allow parallel, private histories for shared commits; you can't have your secrets and share them, too.
Fortunately, there are two common situations where Git makes sense for legal docs: standard forms and public terms. GitHub is in active use in both those areas.
A few pioneers, among them Jason Boehmig, whose Ironclad is a recent YC alum, and Casey Kuhlman, now of Eris Industries, have done work on "open" form contracts in plaintext markup tracked with Git. Jason lead the effort to make the Series Seed financing documents available on GitHub: https://github.com/seriesseed/equity I've followed in Jason's footsteps with an in-development community revision of Series Seed at https://github.com/seriesnext/seriesnext and an experimental company-to-company NDA at https://github.com/obviousnda/obviousnda (More announcements in this vein to come.) Casey's "Legal Markdown" and later writing for Eris were big inspiration for my current open-source work.
Public terms, like terms of use, fall somewhere in between working on a standard form for the common good and negotiating a contentious agreement. On the one hand, what's good for the service provider may come at user expense, as with arbitration clauses or limits on liability. On the other hand, courts require that users at least have notice and a way to review changes made, and transparency goes a long way to earning user trust and avoiding PR blow-up.
When the users on the other side are devs, Git makes a lot of sense. A number of developer-tools companies use version control to track their privacy policies, and sometimes other company policies. npm, Inc.'s policies, to give one example, are here: https://github.com/npm/policies Many of these use GitHub's "prose diff" support for Markdown.
If you're interested in terms of use, privacy policies, and the like, I've written about how my open-source work on "Common Form" (https://commonform.github.io), a schema and content-addressing system for modular legal documents, will apply to those terms: http://writing.kemitchell.com/2015/08/24/TOS-Already-Read.ht...