The link everyone should see is the demo: http://pcottle.github.com/learnGitBranching/?demo

That shows a few example commands, the completion of a level, and finishes with the help dialog.

Some interesting technical highlights

- I made heavy use of javascript "Promises" to route control through the entire app. The source code has some nice examples, but it would be callback spaghetti without it

- You can import and export trees to share with your friends ("import tree" and "export tree" commands)

- You can build levels from within the app with "build level". The intro diaog should step you through the process

- It even supports interactive rebasing! Try it out with "git rebase -i HEAD~3"

Git is a fairly complex too that can be explained really well graphically. I never understood what I was doing until I saw diagrams in the git manpages and various books around on the internet. I wanted there to be an interactive form of these diagrams but it didn't exist --- so I built it.

9,000 lines of JS later I have this. There's still some polishing to be done, but I'd love for the community to share their knowledge about different git workflows and different ways to explain git concepts.

I tried to make the bar for contributing as low as possible. You can build a level and submit a pull request without even cloning the repo!

"A commit in git is a recorded set of changes that you have made"

Git commits are _not_ deltas. They are entire snapshots of the repository and a single (optional) pointer to an ancestor commit[1]. Git may handle _compression_ in terms of deltas (see 'Packfiles' in [2]), but logically, a commit should be thought of as equivalent to the state of all files that are being tracked. That difference is that if you were only looking at diffs, commits would be the _edges_ of a graph, rather than a node plus a single edge. This is why rebases change the commit SHAs but not merges (and why merges create a new commit). This is why if you are on a merge branch, 'git checkout HEAD~3' may not bring you to where 'git log' would naively suggest.

Version control systems that actually do think of 'commits' as pure 'deltas' are ones such as darcs.

A really good, low level explanation, of git is here

http://git-scm.com/book/en/Git-Internals-Git-Objects

(BUG REPORT) The commit created with 'git merge b2' from branch b1 should have HEAD~1 point to the previous head of b1, not b2.

(that said, this is a really cool thing. :) I look forward to the author adding support for conflict resolution. )

[1] http://git-scm.com/book/en/Git-Internals-Git-Objects#Commit-...

[2] http://git-scm.com/book/en/Git-Internals-Packfiles

That said, the intro lesson introduces commits as exclusively deltas. This isn't accurate, and would probably cause confusion with later concepts.

Commits are really snapshots of a tree object (with probably a whole lot of sub trees, and a whole lot of blobs). Since part of the commit meta-data is the parent sha, it's really easy for git to show you the delta, but at it's core git cares about linked snapshots of trees.

I am now done being anal retentive :-) thanks again for the great site, excited to see it more fleshed out

But overall, this is super handy, great idea :)

How about letting me worry about that and continue anyway? What is the worst that could happen, I have to use a scrollbar?

I had other issues with that level as well. It seems to be teaching inefficient habits by forcing strange rebases rather than a single one with an "edit" on C2. I understand this might be a limitation on the (really cool) visualization, but maybe those levels shouldn't be included if you can't show the most intuitive way (at least to me) to accomplish the goal.

Otherwise, awesome work!

I have trouble understanding the rebase workflow: What is the difference between these two sequences?

    git checkout -b bugFix
    git commit -m "fix"
    git checkout master
    git commit -m "master stuff"
    git rebase bugFix
    git checkout bugFix
    git rebase master

    git checkout -b bugFix
    git commit -m "fix"
    git checkout master
    git commit -m "master stuff"
    git checkout bugFix
    git rebase master
    git checkout master
    git rebase bugFix

Instinctively I would tend to do the first one, but that was not what lesson 4 expected...

After reading these comments, it became obvious how great the thing is and going back with that in mind made the app more enjoyable

I also like the fact that there are no instructions on the page which would make this really useful as a quiz tool to see how students / interview candidates / etc approach the problem space. I fully intend to fork and try to make my own levels when I get some free time.

Great concept. Is this based on something else similar or entirely new?

How did you create the branch visualization? Did you use some sort of library for displaying and animating connected nodes, or is it all coded from scratch?

     git checkout -b bugFix
     git commit
     git checkout master
     git commit
     git merge bugFix master

     git branch bugFix
     git commit
     git checkout master
     git commit
     git merge bugFix master

Another direction you can go with this is to make a series of Git puzzles. Basically, starting with this diagram A, convert to diagram B in the least number of moves. To be extra useful, these could revolve around common Git pitfalls.

Suppose I'm in master and already modified a file, and now I notice that it would be better to work on a devel branch with those changes, so I could pull upstream changes from master and merge locally. I think I did something like this:

  git stash
  git checkout -b devel
  git stash apply
  git add file.txt
  git commit -m "XYZ new changes" 

  git checkout master
  git fetch
  git rebase origin/master (to avoid an empty merge, changes
                            upstream were in independent files)
  git merge devel (to get commit "XYZ")

I built it about a year ago, mostly for learning and fun. I haven't advertised it a lot but it seems relevant in here. I hope it's not off topic!