You've sent it. Everyone has.
An email with a subject line that reads something like: "Merger Agreement — FINAL_v4_revised_JT_edits_ACTUALLYFINAL.docx"
And somewhere in that chain of files is a version that went to the client by mistake. Or a clause that got quietly removed and nobody noticed. Or a dispute — weeks later, in a meeting nobody wanted to be in — about who changed what and when.
This is not a technology problem. It's a documentation problem. And it has a solution that software engineers figured out decades ago. It's called Git, and it's quietly changing how governments write laws, how legal teams manage contracts, and how the most forward-thinking firms in the world handle document history.
This article is for anyone in the legal world — lawyers, paralegals, legal ops professionals, law students — who has never heard of Git, or has heard the name and assumed it wasn't for them. By the end, you'll understand exactly what it does, why it matters for legal work specifically, and how it's already being used at the level of national and municipal law.
Part One: What Is Git? (Without the Jargon)
Let's start from the very beginning.
Git is a system that tracks every change ever made to a document — who made it, when, and why.
That's the core of it. Everything else is detail.
Imagine you're drafting a contract. Every time you save a version, Git takes a snapshot. Not just of what the document looks like now, but of exactly what changed since the last snapshot — every word added, every word deleted, every clause rewritten. It stores all of this in a neat timeline, and it never throws any of it away.
Now imagine you have three colleagues also working on the same document. Git tracks all of their changes separately. It can show you a side-by-side comparison of any two versions. It can show you who changed a specific clause on a specific date. And if a change was a mistake, you can go back — not to "yesterday's version" saved somewhere in your email, but to any specific moment in the document's history, with one command.
Here are the key terms you'll see throughout this article, explained in plain English:
Git Glossary for Non-Developers
Repository (or "repo"): The project folder. Not just the files, but the entire history of every change ever made to them. Think of it as a filing cabinet that never forgets anything.
Commit: A saved snapshot. Each time you commit, you're saying: "I'm done with this set of changes. Lock them in." You also write a short message explaining what you did — like a mandatory comment next to a redline. Example commit message: "Removed arbitration clause per client instruction on 14 March call."
Branch: A parallel version of the document. You can create a branch to explore a different direction — say, draft the contract with a different indemnity structure — without touching the main version. If the branch works out, you merge it in. If it doesn't, you delete it. Nothing is lost, nothing is broken.
Merge: Combining two branches back into one. Git is smart enough to do this automatically in most cases — and in cases where two people changed the same clause differently, it flags the conflict and asks you to resolve it manually.
Diff: Short for "difference." A diff shows you exactly what changed between two versions, line by line. Added text in green, removed text in red. This is Git's version of tracked changes in Word — except it works across every file, every version, forever.
Pull Request (or PR): A formal proposal to merge one set of changes into another. In a legal context, think of it as a junior associate submitting a draft for a partner's review. The partner can see every change, leave comments on specific lines, request revisions, and approve or reject — all in one place.
git blame: A command (the name sounds harsh, but it's standard) that shows, for every line of a document, who wrote it and when. In a legal context, this is an audit trail at the line level.
GitHub / GitLab: Websites that host Git repositories and add a visual interface on top. Git itself is the system; GitHub is a popular place to use it with a web browser rather than a command line.
Part Two: The Problem Git Was Built to Solve — and Why Law Has the Same Problem
Git was invented in 2005 by Linus Torvalds, the creator of Linux, to manage something extraordinarily complex: millions of lines of code being edited simultaneously by thousands of developers around the world.
The legal profession faces a structurally identical problem.
Large contracts can run to hundreds of pages. Multiple parties redline the same document over weeks or months. Clauses are added, removed, reworded, restored. Different versions circulate between firms, clients, opposing counsel, and regulators — sometimes simultaneously. And at any moment, someone might need to answer the question: "What was in version seven? And who approved the change from version seven to version eight?"
Right now, most law firms answer that question by digging through email chains. Some use document management systems (DMS) like iManage or NetDocuments, which offer basic version tracking — better than email, but still a long way from what Git provides. The difference is intent and precision: a DMS tells you that a document was saved as a new version at 3pm on Tuesday. Git tells you exactly which words changed, which words were deleted, who made each change, and what note they left explaining why.
That distinction matters enormously in legal work, where the why behind a clause change can be as legally significant as the change itself.
Part Three: What Git Actually Looks Like in a Legal Context
Let's make this concrete with a scenario.
Scenario: The M&A Contract
A mid-sized law firm is handling a merger. The acquisition agreement is 180 pages. Three partners, two associates, and outside counsel for the other party are all making changes over six weeks.
Without Git, the workflow looks something like this: the document circulates by email. Each person saves a new copy with their name and a date in the filename. After two weeks, there are fourteen versions in a shared folder. Someone overwrites the wrong file. A clause added in version six mysteriously disappears in version nine. Nobody is sure when it happened or why. The client asks for a change history. The associate spends three hours reconstructing it from email timestamps and hoping they haven't missed anything.
With Git, every change is committed with a message. The history looks like this:
March 3 | J. Thompson | "Added force majeure clause per client call 3/3"
March 5 | S. Patel | "Revised indemnification cap — reduced to $2M per opposing counsel"
March 7 | J. Thompson | "Removed arbitration clause — client preference, confirmed in writing"
March 10 | R. Chen | "Added governing law clause — New York jurisdiction agreed"
Each of those entries is a permanent, timestamped, attributed record. Click any one of them and you see a precise diff — every word that was added or removed, shown side by side with what was there before. The entire six-week history of the document is reconstructable in seconds.
If someone asks: "When did the indemnification cap change, and who authorised it?" — the answer is one click away.
Scenario: The Contract Dispute
Two parties end up in litigation over the terms of a supply agreement. The dispute centres on whether a limitation of liability clause was present in the version that was agreed upon, or was added afterward.
A law firm using Git can produce a complete, timestamped audit trail: when the clause was added, by whom, with what commit message. It's the equivalent of a notarised log of every document event. This kind of traceability is increasingly valuable in disputes, and some courts are beginning to expect it.
As one legal technology expert put it: "In a real estate M&A dispute, a firm can avoid liability by producing a version history that shows exact approval timestamps. That audit trail is their first line of defence in court."
Scenario: The Policy Document
A large financial institution needs to update its internal compliance policy whenever regulation changes. The policy is 60 pages. Different departments own different sections. Currently, a new Word document is emailed around every quarter with tracked changes turned on — and then someone always accepts all changes before sending it on, losing the revision history.
With Git, each department works on their section in a branch. Changes are reviewed via pull requests before being merged. The compliance officer has a complete history of every policy change going back years — who changed what, when, and what note they left. When regulators audit, the firm can demonstrate exactly how policies evolved in response to specific regulatory changes.
Part Four: Governments Already Do This — And the Results Are Striking
Here is where the story becomes genuinely surprising.
Legal professionals often assume Git is a developer tool that would need to be "translated" for law. But some governments have already made that translation — and the results show both the enormous potential and the real limitations.
Washington D.C.: The City That Put Its Law on GitHub
In 2018, the District of Columbia did something unprecedented: it made GitHub the official, authoritative source for D.C.'s legal code.
A civic hacker named Joshua Tauberer found a typo in the District of Columbia's legal code and corrected it using GitHub, highlighting the groundbreaking way the District manages its legal code. The District publishes the law on GitHub as an authoritative source — it is where the DC Council stores the digital versions of enacted laws, and this source feeds directly into the Council's DC Code website.
The practical effects were immediate and meaningful. With the District's previous codification contractor, updates to the DC Code were published three times a year, with a five-to-seven month delay in seeing the latest laws. The Open Law Library has shortened the publication process to about a week after a law is enacted.
That is not a marginal improvement. It means citizens, lawyers, and courts are working with law that is weeks old instead of months old. The transparency gain is equally significant: anyone in the world can see exactly what changed in D.C.'s legal code, when, and in what version.
The U.S. Congress: The Comparative Print Project
At the federal level, the U.S. House of Representatives has been working on what it calls the Comparative Print Project — an effort to bring version control to federal legislation.
The U.S. Law Revision Counsel compiles the U.S. Code through careful analysis of new laws. Since 2011, the LRC has been using and publishing the results of this analysis in XML format, making it feasible to automatically match the "before" to the "after" text and produce a redlined version showing the changes in context.
The project addresses a problem that most people don't realise exists: for many laws, particularly those that were recently changed, there is no current official version and no way to see a precise history of amendments over time. In the Canadian House of Commons, a lack of version control led to embarrassing headlines when the Senate debated the wrong version of a government bill — for the second time in less than three months.
The goal of the Comparative Print Project is to create what Git provides automatically for every software project: a legally relevant diff — the ability to see exactly how a new bill changes existing law, before it passes.
New Zealand and the "Better Rules" Movement
Further afield, New Zealand has been a pioneer in what it calls the "Better Rules" approach — a methodology for drafting legislation that is machine-readable, unambiguous, and collaboratively developed by teams of policy experts, lawyers, and technologists.
The approach represents a fundamental shift in how governments draft rules, bringing multi-disciplinary teams together to look at what's proposed in a Bill or Amendment, virtually model and test the draft rules using real data and likely scenarios, to ensure the rules are implementable and more likely to achieve the intended outcome.
This is not just about Git specifically — it's about adopting the principles of version-controlled, collaboratively-drafted, machine-readable documents. The OECD selected this approach from over 500 public sector innovation case studies for its Global Trends Report.
The Honest Limitation: Git Wasn't Built for Law
It's worth being clear about something: Git is not a perfect fit for legal documents out of the box. It was built for code — plain text files that follow predictable structures. Legal documents, with their complex formatting, cross-references, page and line numbers, and jurisdiction-specific drafting conventions, don't map cleanly onto Git's assumptions.
Git is designed specifically for the software development process. The legislative process has a quite different set of requirements and traditions which must be met. It simply isn't possible to bend and distort the legislative process to fit the model prescribed by Git.
What this means practically is that the concepts of Git — version history, commits, branches, diffs, pull requests — are the valuable thing, not necessarily Git the exact tool. The future of legal document management will likely involve software built on Git's principles but designed specifically for legal workflows: tools that understand redlining conventions, can handle Word and PDF formats, and integrate with existing legal technology stacks.
Some of that software already exists. Tools like Ironclad, ContractSafe, and Hyperstart bring version-control thinking to contract management. The legal document management platforms used by major firms — iManage, NetDocuments — are adding increasingly Git-like features. The direction of travel is clear.
Part Five: How to Actually Start Using Git's Thinking in a Law Firm Today
You don't need to install Git on day one to start applying its principles. Here is a practical roadmap, from simplest to most advanced.
Level 1: Adopt the Commit Message Habit
The most immediately valuable thing Git brings to legal work is the discipline of explaining every change.
Start by making it a firm policy that every time a document is sent with changes, the email must include a brief note describing exactly what changed and why. This isn't Git — it's just good practice. But it's the same habit that makes Git's commit log so powerful.
Example: instead of "Please see attached revised agreement," write: "Revised Section 4.2 — removed liquidated damages clause per opposing counsel's objection on 15 March call. Added right of termination for convenience at client's request."
That note, attached to every revision, turns your email chain into something resembling a commit log. It takes thirty seconds and creates a paper trail that could be invaluable months later.
Level 2: Use a Document Management System with Proper Version Control
If your firm is still managing documents through a shared drive or email attachments, the first step is a proper DMS. Systems like iManage, NetDocuments, or Clio all offer version tracking, access controls, and audit trails. After 20+ years in legal technology, version control is on the short list of things a law firm's document system absolutely must do well.
This is not the same as Git, but it puts in place the infrastructure — centralised storage, version history, attribution — that Git formalises.
Level 3: Use Contract Lifecycle Management (CLM) Software
For firms that handle high volumes of contracts, CLM platforms like Ironclad, Hyperstart, or Icertis bring Git-like thinking directly to legal workflows: structured approval workflows, complete version history, automated audit trails, and clause-level tracking.
When legal teams get version control right, the payoff is huge. You can prove who made what changes, when they were made, and whether they were approved. Every edit is logged, every comment saved, and access is role-based. You avoid costly he-said-she-said disputes.
Level 4: Explore Git Directly for Plain-Text Legal Work
For legal professionals who work with policy documents, regulatory submissions, or internal guidelines — documents that don't require complex Word formatting — using Git directly is increasingly viable.
Plain text documents (including Markdown, a simple formatting language) work beautifully with Git. A compliance team that manages its policy documents as plain text files in a Git repository gets the full benefit: line-by-line history, branching for draft alternatives, pull requests for review, and a permanent audit trail.
This is not for everyone. But for legal operations teams, in-house counsel, or legal technology professionals, it's worth exploring. GitHub provides free accounts and extensive documentation. A few hours of setup creates infrastructure that pays dividends for years.
Part Six: The Bigger Picture
There is a version of the future where the opacity of legal documents — who added that clause, when this term was agreed, what the original draft looked like — becomes a relic of an older way of working.
What if you could fire up git blame and see who is responsible for writing each individual line of a bill? Think of how easy it would be to track those responsible, especially if the actual writer was tracked, and not just the bill's official sponsor.
That vision applies as much to a corporate acquisition agreement as to a piece of legislation. Legal documents are, at their core, a record of decisions made by human beings over time. Version control doesn't change the substance of those decisions. It just makes the record honest.
The legal profession has long prided itself on precision — on the exact meaning of words, on the careful drafting of clauses, on the documented intent behind every contractual provision. Git is simply a technology that makes that precision verifiable. Every change, every decision, every iteration: provably recorded, forever.
The question isn't whether version control belongs in legal work. It clearly does. The question is how long it takes the profession to fully recognise something that software engineers worked out decades ago — and that Washington D.C. has already proved works.
TL;DR
- Git is a system that tracks every change to a document: who made it, when, and why
- In legal terms: it's a permanent, timestamped audit trail for every draft, revision, and decision in a document's history
-
The problem it solves: the
FINAL_v4_ACTUALLYFINAL.docxemail chain, missing revision history, and undocumentable clause changes - Key concepts: repository (project folder), commit (saved snapshot + explanation), branch (parallel draft), diff (what changed), pull request (formal review), git blame (who wrote each line)
- Real-world legal use: Washington D.C. uses GitHub as the official source for its legal code; the U.S. House of Representatives' Comparative Print Project applies version control to federal legislation; New Zealand's "Better Rules" programme uses similar principles for drafting law
- For law firms today: start with commit message discipline, invest in a proper DMS or CLM platform, and for plain-text documents, consider using Git directly
- The honest limitation: Git was built for code, not legal documents — but its principles are invaluable, and legal-specific tools are catching up fast
If this sparked a question or a "we actually tried something like this" story, share it in the comments. The legal technology conversation is just getting interesting.
Top comments (0)