# A data model for Git (and other docs updates)

DevFeed: [A data model for Git (and other docs updates)](<https://devfeed.tech/articles/a-data-model-for-git-and-other-docs-updates-21123.md>)

Original publisher: [Read original article](<https://jvns.ca/blog/2026/01/08/a-data-model-for-git/>)

Author: Julia Evans

Published: 2026-01-08T00:00:00Z

Content type: article

Language: en

Sources: [Julia Evans](<https://devfeed.tech/sources/julia-evans.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [Documentation](<https://devfeed.tech/topics/documentation.md>), [Maintainers](<https://devfeed.tech/topics/maintainers.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [data](<https://devfeed.tech/topics/data.md>)

Tags: [docs](<https://devfeed.tech/tags/docs.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [git](<https://devfeed.tech/tags/git.md>), [maintainers](<https://devfeed.tech/tags/maintainers.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [review](<https://devfeed.tech/tags/review.md>)

## AI overview

The article describes updates to Git's official documentation, including a new data model explaining objects, references, indexes, commits, and branches. It also discusses improving Git's core man pages through review and feedback from about 80 test readers.

## Source excerpt

Hello! This past fall, I decided to take some time to work on Git's documentation. I've been thinking about working on open source docs for a long time - usually if I think the documentation for something could be improved, I'll write a blog post or a zine or something. But this time I wondered: could I instead make a few improvements to the official documentation? So Marie and I made a few changes to the Git documentation! a data model for Git After a while working on the documentation, we noticed that Git uses the terms "object", "reference", or "index" in its documentation a lot, but that it didn't have a great explanation of what those terms mean or how they relate to other core concepts like "commit" and "branch". So we wrote a new "data model" document! You can read the data model here for now. I assume at some point (after the next release?) it'll also be on the Git website. I'm excited about this because understanding how Git organizes its commit and branch data has really helped me reason about how Git works over the years, and I think it's important to have a short (1600 words!) version of the data model that's accurate. The "accurate" part turned out to not be that easy: I knew the basics of how Git's data model worked, but during the review process I learned some new details and had to make quite a few changes (for example how merge conflicts are stored in the staging area). updates to git push, git pull, and more I also worked on updating the introduction to some of Git's core man pages. I quickly realized that "just try to improve it according to my best judgement" was not going to work: why should the maintainers believe me that my version is better? I've seen a problem a lot when discussing open source documentation changes where 2 expert users of the software argue about whether an explanation is clear or not ("I think X would be a good way to explain it! Well, I think Y would be better!") I don't think this is very productive (expert users of a pie