The problem Git solves
Imagine a piece of software is a 4,000-page contract that fifteen lawyers are editing simultaneously. Some are fixing typos, some are adding new clauses, some are restructuring whole sections. Without a system for tracking every edit, the file would be chaos within a week — and a year later nobody would remember why a specific clause was changed in March.
Software has this exact problem at a wildly larger scale. A real codebase has thousands of files, hundreds of thousands of lines, and changes flowing in continuously. Git is the system that solved this problem in the early 2000s and is now the absolute standard. Every reputable software project on earth — Microsoft Office, the Linux operating system, the website you're reading this on — uses Git.
The vocabulary, mapped to legal analogies
| What developers say | What it actually means |
|---|---|
| Repository (or "repo") | The case file. The whole project, with its complete history. Lives in a folder on your computer or on a hosting service like GitHub. |
| Commit | A single Bates-stamped change. "At 3:14pm on Tuesday, Sarah added two fields to the intake form." Each one has a unique ID and a one-line note describing what it changed and why. |
| Branch | A working copy where you can experiment without affecting the main file. Like an associate's draft markup of a contract — kept separate until it's ready to go in. |
| Merge | Folding one branch's changes back into the main file. Reviewing a markup and accepting the changes. |
| Push | Sending your local commits up to a shared online copy (usually on GitHub) so others can see them. |
| Pull | Bringing down somebody else's commits from the online copy onto your computer. |
| Pull request (PR) | Formally proposing your branch's changes for inclusion in the main file. Includes a discussion thread, line-by-line review, and an approval step. Treat it as a markup-with-comments that gets accepted, modified, or rejected. |
| GitHub / GitLab / Bitbucket | Hosting services for Git repositories. They're to Git what Westlaw is to caselaw — the place where the canonical copy lives, with extra collaboration features around it. |
Why this matters even if you never run a Git command
If you build any software, even casually, you are going to encounter Git. When you publish a tool from BuildLegal, the platform stores its complete history in a Git repository under the hood. If you ever hire a contractor to extend a tool you started here, they are going to ask you for a Git repository. If you ever look at code on GitHub to see how something works, you are looking at a Git history.
There is a cultural reason it matters too. The discipline of small, named, traceable changes — "this change does this one thing, here's why" — is exactly the discipline that keeps software trustworthy over time. It's the same instinct that keeps a litigation file defensible. Software professionals take this seriously and you'll be taken more seriously yourself when you understand why.
What you'll see in BuildLegal
You won't write Git commands. The platform handles all of that. But you may see things like:
- A version history of your project, where each entry is a commit — the AI made some change, named it, and saved it. You can roll back to any prior version.
- If you ever export your project (some plans support this) you'll get a Git repository, ready to hand to a contractor or push to GitHub.
- When something breaks, the AI can look at the commit history to figure out what changed and why — exactly the same instinct a developer would use.