"Bottom up" rationale for how Git works

I remember reading a great document a while back explaining the rationale for Git being designed the way it was. At least, I'm pretty sure it was specific to Git, but it might have been for just the DVCS concept. It wasn't so much focused on the actual commands you would put in; Instead, it was primarily focused on how to solve the problems of working offline, keeping your versions up to date between people, tracking changes between branches, etc., and how Git solves these problems. (Again, it might have been a different DVCS, but I think it was Git)

Essentially, the document was a casually-written story about how a programmer might keep track of their files, and how Git (or whatever) helps solve these problems. I remember an early part about how one might keep their old versions of a document in some "backup" folder, labelled in a file to keep track of each version, and how they might need to work on a bug while in the middle of coding a new feature, so the "tracking file" grows to include branches.

I really enjoyed reading it, as it clearly explained a lot of the reasons behind certain features and was a great "story of version control" as well. I'd like to find it agai开发者_如何学Pythonn.

It sounds like you might be referring to The Git Parable by Tom Preston-Werner.

The story describes how one might derive a system similar to Git by starting with simply making whole tree copies (snapshots). It builds on these snapshots to add branches, tags, distributed/offline workflows, merges, etc.

It sounds like you might be looking for one or both of the following:

• Git from the Bottom Up
• Git Magic