Hacker News new | ask | show | jobs
by hack_edu 5104 days ago
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.

2 comments

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.
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.