[weavejester]

In a nutshell... a project can be described in terms of the changes a user makes over time.

In Git, these changes are called "commits".

Commits contain a change a user has made to the code and some additional useful metadata. This metadata includes the time the change was made, the user's name, a message to describe in general terms what the change was (that -m thing), and so on.

Git itself is a database that stores these commits. Each commit links back to the change before it, forming a chain.

If a single person is working on a project, this may be a linear chain of commits, but if multiple people are working on the same project, two people might make a change to the same text at the same time.

So maybe one person writes "The Nexus 7 costs £159", and another person writes "The Nexus 7 costs $199". If this happened, the chain would split; you'd have two valid changes made to the same text. The act of reconciling these chains is called a "merge". We might choose to use one version or the other, or to combine the two, such as "The Nexus 7 costs $199 (£159)".

That's basically it. The only other thing Git does is to allow you to give commits a human-readable name so you can refer back to them later.

[hack_edu]

Again, this is a gross oversimplification that describes only generic version control concepts and none of the powerful features that .

Go ahead and try explaining a rebase without trying to broach the concepts of time travel. How about why having a local copy of all commits/branches/etc related to the repository is helpful, or even at all possible, without relating it to a simpler client/server version control system.

[grey-area]

Go ahead and try explaining a rebase without trying to broach the concepts of time travel.

A project can be described in terms of the changes users make over time, and that lets us undo any previous changes all the way back to the beginning of the project.

I don't think that explanation is overly technical or difficult to understand, and the generic features of version control which you dismiss are precisely those that make it most useful - the above paragraph in my opinion encapsulates most of what is useful about a VCS. To extend the above to cover a rebase:

A rebase is just merging other people's changes with yours, so that you end up with a merged version of the files, but with details that mean it looks slightly cleaner in histories - it's not even something many people will ever have to do. As to why having a local copy is useful, who cares, it's a detail of how the VC works?

This really is not rocket science - while git can at times be frustrating if you hit a particular problem which it doesn't consider important like expunging files from history, the basics are very very simple. You really only need 3 commands for day to day use:

  git pull (get other people's changes)
  git push (send your changes to others)
  git commit (commit a change to your local copy)

Actually for commit I just add all new non-ignored files (using an alias like this: "git add --all .;git commit -a -m") to save typing, otherwise I might have to use git add as well now and then, so I use commit "My message here". If the above commands are scary, there are various alternatives to VCS, but they're not as good - you can rename your files when you make a change, you can use something like Apple's Time Machine, etc. All of those work, but are not really as easy as VC when you're changing a lot of files.

[weavejester]

The core concept of Git is simple. All its more complex features can be derived from the idea that Git is a database of commits (changes + metadata).

A rebase is the act of changing the parent, or base, of a commit. So instead of a change being made to version A, you make the same change to version B. No time travel metaphors need to be involved, and IMO only complicate a very simple concept.

The harder part is explaining why you'd want a rebase.