How to version contracts with Git

A supplier agreement goes through five drafts in three weeks. The drafts travel as email attachments: agreement_v3.docx, agreement_v3_final.docx, agreement_v4_clean.docx. On signing day someone asks: when did the liability cap drop from twelve months of fees to six, and who agreed?

Nobody can answer from the attachments. Tracked changes were accepted in one round and lost in the next; comparing draft two with draft five means reading both side by side.

Version control solves this for software, and it solves it for contracts too, as long as the contract is text.

What version control gives a contract

Git records a document as a series of commits. Each commit is a saved state, with three facts attached:

• who made the change,
• when,
• why.

That answers the questions negotiations and audits ask: which clause changed between two versions, who last changed a line, and what the agreement said on a given date.

Word’s tracked changes live in one file and vanish once accepted. Git keeps every state and compares any two, not just neighbours.

Step 1: write the contract as Markdown

Git compares text line by line, so the contract has to be text. Markdown fits: headings for sections, numbered clauses, nothing hidden in formatting.

# Supply Agreement — Acme Ltd.

## 9. Limitation of liability

9.1 Each party's total liability under this agreement is limited to the fees paid
in the six months before the claim.

9.2 Clause 9.1 does not apply to breaches of confidentiality (clause 12).

Put one sentence or sub-clause per line, and a diff shows the sentence that changed.

Step 2: give each agreement a place

• one folder per counterparty, such as contracts/acme/;
• one Markdown file per agreement, such as supply-agreement.md;
• the signed PDF beside it, such as supply-agreement-signed-2026-10-01.pdf.

Git keeps every version of the PDF too, just without a line-by-line diff. The Markdown is the working copy; the PDF is the record of what was signed.

Step 3: commit at each meaningful revision

A new draft for the other side, a change agreed on a call, a fix from your own review: each is worth a commit. Write the reason in the message:

Reduce liability cap to six months of fees

Requested by Acme in the call on 24 September; approved by finance.

Six months later, that message answers “who agreed to it”.

Step 4: compare versions and trace a clause

To see what changed between two drafts: git diff, or GitHub’s compare view. Only removed and added lines are shown.

To find who last changed a clause: blame. GitHub’s blame view shows, beside every line, the commit that last touched it, with author, date and message.

Step 5: review before a change counts

Make changes that need approval on a branch and open a pull request. The reviewer sees exactly the lines that would change, comments, and approves. The main branch holds only agreed text.

Step 6: protect the history

Every commit is identified by a hash of its content and the history before it. Changing an old commit changes every later hash, so a rewritten history no longer matches earlier copies.

Someone with write access can still force-push. On GitHub, protect the main branch and block force pushes and deletions. Tag the signed version, such as signed-2026-10-01, so it is always easy to find.

What Git does not do for you

Git does not negotiate. If the other side sends a redlined Word file, someone still turns those changes into commits. Git does not format either; for signature, export the Markdown to PDF or Word with a converter such as Pandoc.

What it does is keep an honest record of the text: every version, who changed it, and why.

Doing this without the command line

MyGitNotes is a Markdown workspace on a Git repository you own. Write the contract in the browser, review the diff before you commit, and get a commit message written from what changed. The files stay in your repository, so the record does not depend on us.

If your legal team wants this for many agreements, see the legal and documents page.