I first adopted Git in early 2017. Initially I used it only for writing code.

In 2019, I applied Git to my legal work in full measure. I strictly enforced its use; I put almost every source file for my legal documents (meaning drafts or revisions of cause papers, correspondences, submissions/briefs, memos, etc) through Git and Sublime Merge.

Over the course of a year, I discovered how useful Git is to legal practice. Its benefits extend beyond just version control and branching. For instance, and with Git:

1. I can now pinpoint what files were being singularly or jointly worked on in any particular case or matter at any point in time. This matters a lot, as litigation work often stretches years. You will forget things over time, and how/when files came to be finalized. If misunderstandings arise between colleagues or with clients, your Git log history can arrest those disputes.

2. I no longer have to browse through different documents to compare what has been worked on, since Git lets you trace changes to each unit-of-work in a unified fashion and chronologically in a single log-history. This can be done at a significantly faster rate compared to the time-wasting and confusing exercise of browsing through multiple open document/email/discussion threads. This approach also minimizes the context-switching penalty when juggling cases, and speeds up recall when I’ve to prepare for meetings or explain thought processes to co-counsel and clients.

3. I’ve not had the dreaded “Wait, is this the final copy?” or “What exactly did I change?” or “Why is there another draft?” questions at all. I preserve only the final draft of documents, while Git records all (exact and historical) changes in between. Multiple draft copies become unnecessary if you keep Git hunks (‘changes’) atomic and your commit messages (‘change records’) meaningful.

Git’s Other Use Cases

Git’s ability to delve into a particular unit-of-work and its associated comments - months or years after you’ve drafted it - is extremely invaluable for other use cases too:

1. Rules compliance. The law may require some legal points to first be held back. For instance, you must plead facts, but cannot plead evidence proving those facts. A careful solicitor must therefore draft pleadings that only hint at available evidence or testimony, and remember to raise them up at trial later. Recording consciously-made decisions/additions/omissions in your repository’s log history makes them easier to find than leaving them strewn across various document drafts or to-do lists.

2. Facilitating recall. As time passes you will no longer immediately recall why you prepared or argued a particular legal point a certain way. This is very common, especially when you’re dealing with thousands of papers across different cases, or as you delegate work, or if you lose interest, or more commonly, when life steps in. If applicable strategies/instructions/points of law are forgotten, inconsistencies could appear, with potentially fatal consequences. A well-maintained Git repository serves as an alternate reminder system.

3. Managing case theories/arguments. Lawyers should not just throw out old ideas and arguments, as they may serve some other use - in rebuttal, or in anticipation of arguments, or to fashion new legal strategies. As you revise legal arguments for strength, various parts are often chiselled away; I find it best to preserve the removed parts somewhere along the historical record, than in separate documents that you later forget where you have to dig for.

4. Billing. It’s comforting to consult your log history as you’re preparing bills to know what honest work you’ve done. The log history can also serve as a form of evidence if your work is ever questioned and justification becomes necessary. (I have mostly excellent clients and I’d like to think that I do competent work, so it has never reached this extent. But I would be ready if it ever does go that far.)

All in all Git is useful to my legal practice. Explore and see if it is useful to yours.

I’ve had a few other revelations, particularly on Git’s differing application for legal work versus code (e.g. choices of monolithic/micro repos, branching uses, merging/rebase considerations, filename/renaming behaviours, etc). These topics are beyond the purpose of In Personam; I will only write about them if there is sufficient interest.