The terminology here is a bit muddled. Git commits represent a merkle tree of commits where the each commit describes changes to a graph of objects (aka files a

The terminology here is a bit muddled. Git commits represent a merkle tree of commits where the each commit describes changes to a graph of objects (aka files and directories) represented by the ancestor commit (or commits in case of a merge). In the case of a merge, the commit includes conflict resolutions for any lines modified by multiple ancestors. The way that is stored internally with binary deltas is clever and interesting but not all that relevant to end users. It's convenient that it's compact and fast. But otherwise it's just an implementation detail. From the outside, each commit basically represents a snapshot of the whole system. And that's exactly what you get when you check one out. It's the fluff in the git porcelain and various Git UIs that muddle the waters by giving us different tools to produce new commits, stashes, staging, tools for flaging and resolve conflicts (two commits modifying the same thing), rebasing, squashing, etc. That's where diffs, git patches, merge algorithms and other tools come in. Some of that is part of git. And some of it can be added via third party tools, uis, etc. Or even git alternatives that work in a compatible way. But in the end they just help you produce a new git commit. Most of us just use the stuff that comes with Git and our IDEs. And of course it doesn't help that most git users have not read the manual section on the Git internals, have a poor understanding of how all this works, and generally only know about and use a small fraction of the git commands and options. It's a complicated tool. And it undeniably works very well for extremely large open source communities.