Skip to main content
Git is version control software. It tracks every change to every file in your documentation, records who made it and when, and lets multiple people work on the same content without overwriting each other. If you’ve never used Git before, it can feel unnecessarily complicated at first. This course strips it back to what matters for documentation work. Most tools for writing — Google Docs, Notion, Confluence — have their own ways of handling collaboration and history. So why do documentation teams that use Mintlify work with Git instead? Git solves three problems that matter a lot for documentation: tracking what changed, enabling collaboration without chaos, and making sure changes are reviewed before they go live.

​
Track every change, forever

Git keeps a complete history of every change ever made to your documentation. Every edit, every addition, every deletion is recorded, along with who made it and when. When a support ticket reveals that a page is wrong, you can look back at the history and see when it changed and what it said before. When someone asks “did we ever document X?”, you can search the history rather than trying to remember. Mintlify connects directly to your Git repository, which means this history is both a backup and the source of truth for everything on your live documentation site.

​
Work in parallel without overwriting each other

Without version control, two people editing the same document at the same time is a recipe for lost work. The last person to save wins, and the other person’s changes disappear. Git solves this with branches. Each person works on their own copy of the docs, and Git handles merging those changes together. Conflicts (cases where two people changed the same thing) are surfaced explicitly so they can be resolved deliberately rather than silently overwritten. For a docs team where writers, engineers, and product managers are all making changes, this matters constantly.

​
Review before publishing

In most writing tools, saving a document publishes it. There’s no step between “I wrote this” and “the world can read this.” Git introduces a review step called a pull request. Before any change goes live on your Mintlify site, it can be reviewed, commented on, and approved by someone else on your team. This is how documentation teams catch errors, maintain consistency, and keep the bar high without creating bottlenecks. Mintlify builds on this by generating a preview deployment for every pull request. Preview deployments are live versions of your docs site with the proposed changes applied, before anything is merged. You can share the preview link with reviewers so they can see exactly what the published result will look like.

​
Why Mintlify is built this way

Mintlify’s docs-as-code approach isn’t just a technical choice. It’s built on the idea that documentation has the same collaboration and quality needs as software, and the same tools that help engineering teams ship reliable code can do the same for docs. The workflow becomes second nature quickly. Next up: Core Git concepts — a plain-language breakdown of the Git terms and commands you’ll use every day.