--- title: "Git" description: "A version control system for managing change, collaboration, review and release across files over time." category: "AI and tooling" canonical: "https://contentlexicon.com/git" updated: "2026-10-11" --- # Git _AI and tooling_ > A version control system for managing change, collaboration, review and release across files over time. Git records changes to files, but more importantly it gives teams a way to work on the same material without overwriting one another, to review changes before they are accepted, to compare versions in detail, to merge work from different people and to restore an earlier state when something goes wrong. Its basic units are commits (saved changes), [branches](https://contentlexicon.com/branch) (parallel lines of work), merges (bringing changes together) and tags (named states you can return to). Hosting services such as GitHub and GitLab add [pull requests](https://contentlexicon.com/pull-request), a formal review step before changes are merged. Version history is only the start. Git is a system for change management and collaboration: who changed what, in which branch, against which version, with whose review and how that change became the current state. That's why software teams use it for far more than code, and why [content teams](https://contentlexicon.com/content-team) increasingly use it for documentation, [content models](https://contentlexicon.com/content-model), [prompts](https://contentlexicon.com/prompt), [schemas](https://contentlexicon.com/schema), design tokens, configuration, [Markdown](https://contentlexicon.com/markdown) content and whole [websites](https://contentlexicon.com/website). ## Why it matters for content Git makes content work safer, more visible and more deliberate. It lets a team draft a major change on a branch without touching the live version, compare two drafts line by line, use a configured hosting [workflow](https://contentlexicon.com/workflow) to require review before something is merged, see what changed between releases and roll back if a change breaks something. It's especially useful where content is structured, reused or shipped through systems rather than pasted into a single visual editor, the kind that shows the page as you type. A content team can use Git to manage a [style guide](https://contentlexicon.com/style-guide) as a living document, maintain prompts and AI instructions with a proper audit trail, coordinate edits to a content model with developers, keep translations and regional variants aligned, and publish documentation or websites from a trusted source rather than from whichever copy someone last downloaded. It earns its place when several people touch the same material, or when getting the live version wrong would be expensive. ## How AI changes the picture Prompts, retrieval sources, schemas and guidance change constantly, and small edits can have large effects. When an assistant starts answering differently on a Tuesday, a diff can show that someone changed one line of its instructions on the Monday. Git gives those assets provenance, review and [rollback](https://contentlexicon.com/rollback). It also makes experimentation safer: branches for testing, pull requests for scrutiny, tags for stable versions and diffs that show whether a change altered substance or only wording. ## Questions people ask **Do I have to use the command line?** No. Many people use Git through interfaces such as GitHub Desktop, VS Code, GitKraken or the built-in Git features in other tools. The command line is still the most direct and flexible way to use it, and it makes the underlying model easier to understand, but it isn't a requirement. **Do I have to understand pull requests?** If you're working alone, not necessarily. If you're working with other people, probably yes. On GitHub (GitLab calls it a merge request), a pull request is a formal way to propose a change, review it and discuss it before it becomes the new main version. For content teams, that's the discipline that stops important material being changed casually or invisibly. **Is Git the same as GitHub?** Git is the version control system; GitHub is one popular service built around it, a place to use Git with other people. You can use Git without GitHub, and there are other Git hosting services such as GitLab and Bitbucket. **Is Git overkill for content?** Sometimes. If one person edits a handful of pages in one [CMS](https://contentlexicon.com/cms), Git may add more ceremony than value. But where content is shared, reused, translated, reviewed, published across channels or maintained alongside code and structured systems, Git often becomes the cleanest way to manage change. ## Learn more - [What is Git?](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F) – the Pro Git chapter explaining snapshots, local history and the modified, staged and committed states. - [Learn Git Branching](https://learngitbranching.js.org/) – an interactive way to practise commits, branches and merges through visual exercises. - [Confusing git terminology](https://jvns.ca/blog/2023/11/01/confusing-git-terminology/) – Julia Evans’s plain-language guide to the git terms that trip people up, from detached HEAD to “ours” and “theirs” and fast-forward. Related terms: [Branch](https://contentlexicon.com/branch), [Markdown](https://contentlexicon.com/markdown), [Merge conflict](https://contentlexicon.com/merge-conflict), [Pull request](https://contentlexicon.com/pull-request), [Versioning](https://contentlexicon.com/versioning) This page was last reviewed in October 2026.