Git Architecture Fundamentals
Comments explain and debate Git's core model, including commits as immutable snapshots in a DAG rather than deltas, branches as pointers, and concepts like rebasing, reflog, and history immutability versus common misconceptions.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Git does hide the old commits as well. What git doesn't do is track which commits are replaced by which. So sharing mutable history and seeing how a commit evolved over time requires more heuristic than necessary.
The storage model does not - it is not file-delta based, like SVN and Mercurial. However, you as a developer can (and often do) think of the commits in terms of a changeset or "work introduced" - this is evident in tools that exist like 'rebase' which treats each commit in a branch as a patch and the collection of unique commits on that branch as a patch series and helps you transfer that series elsewhere. The 'cherry-pick' command is similar - it enforces your thinking of each commit as a cha
A Git repo is a DAG of commits, and each commit is a snapshot of your files, along with some metadata. Commits are immutable and point to their own parents. Branches and tags are pointers or labels on commits. Everything follows from that.
Neither it is in git. See the discussions about how rebased commits are often preferred.
It is not! See https://github.com/arxanas/git-branchless/wiki/Architecture#...
That's exactly what the actual git does too.
In case of git it is more like a blocktree, I suppose.
Completely agree.> Which in case of Git is that it's a DAGAnd one step beyond that, that it's a Merkel tree. It's key to understanding stuff like "if I change a commit, it changes all commit after that" or "if I move (cherry pick, rebase) this commit, I'm creating a new one, not really moving".
Branches are just pointers into a graph of commits. The graph cannot be mutated (it can be pruned by garbage collection but that does never happen related to an oh shit event, it takes weeks even in a heavily modified repo). The pointers can be modified to point anywhere else in the graph, which makes things look mutated without being mutated. Using reflog you can get your back to where your pointers pointed to at any earlier point of time.
Isn't that what a branch and a merge commit do?