
Visualizing Git Concepts with D3.js - sebg
http://www.wei-wang.com/ExplainGitWithD3/#
======
pdq
See also "Learn Git Branching":
[http://pcottle.github.io/learnGitBranching/?demo](http://pcottle.github.io/learnGitBranching/?demo)

~~~
ColdHawaiian
The Ungit[1] gui can also help you to visualize git operations like merging
and rebasing commits. Here's the youtube demo:
[https://www.youtube.com/watch?v=hkBVAi3oKvo](https://www.youtube.com/watch?v=hkBVAi3oKvo).

[1]:
[https://github.com/FredrikNoren/ungit](https://github.com/FredrikNoren/ungit)

~~~
kremlin
That's exactly what I was just thinking I wished existed!

------
robbles
This is really cool - I wish I'd had this for teaching git a few weeks ago.

FYI - it looks like branch creation is broken. Creating a branch and following
with `git commit` gives the error "Not a good idea to make commits while in a
detached HEAD state." It's not a detached HEAD, it's a branch.

~~~
Gazler
_Excuse the self promotion_ I wrote a tool aimed at teaching git at
[https://github.com/Gazler/githug](https://github.com/Gazler/githug)

~~~
touristtam
ok, I need to download && install just to see a demo?

Maybe you should create a demo page.

------
wudf
New to git as well as programming in general. This site has helped me
somewhat, but I'm still confused about some basic concepts. Aren't the arrows
all facing the wrong way? What happens to a commit after 'git reset' abandons
it; can the commit be accessed ever again? What's the difference between reset
and revert? How can merge and rebase be trusted? What are the best practices
for how many branches a project should have and how & when should they be
merged? And what are remote tracking branches? Since I only program alone so
far, my friends tell me not to concern myself with these questions until I am
forced to do so in a practical situation... but that doesn't satisfy me.

~~~
raju
I can attempt to answer your questions briefly

Aren't the arrows all facing the wrong way?

>> No, the arrows are in the right direction. Git maintains a Directed Acyclic
Graph (DAG) of commits. Each new commit created points to 0..n parents. So
let's say you were on the first commit, and then you created a new commit. The
newly created commit is the "child" of the first commit, and has a "parent"
pointer that is the SHA of the parent. The parent cannot have pointers to the
children since they don't know that one will be created!

Now, if you were to do a merge between branch a and b, assuming it's not a
fast-forward merge, a new child commit is created that will have 2 "parent"
pointers - the SHA of a and b.

A commit will have 0 parents if it the first commit in a repo.

What happens to a commit after 'git reset' abandons it; can the commit be
accessed ever again?

>> That commit is "lost". I put that in quotes because git dosen't immediately
throw away the commit (rather there is a garbage collection process that will
eventually remove that commit). For the same reason if you happen to know the
SHA of the commit you just reset, then you can do a "git checkout <new_branch>
<sha>" and create a branch off that commit.

One way to get to that "lost" commit is to use "git reflog" \- the reflog
(that is ref-log) is a lot that updates each time the "HEAD" moves. Since when
you do a "git reset" the HEAD moves from the current commit to another one,
the reflog will record that.

What's the difference between reset and revert?

>> "reset" is "destructive" in that it can leave dangling commits. A dangling
commit is a commit that nothing else points to. Remember the DAG? Well that
means that every commit (except) the last commit has a child pointing to it.
And who's pointing to the last commit? The branch, and the HEAD. If a commit
has NO ONE pointing to it, it is eligible for garbage collection.

Furthermore, since a reset can "delete" commits, one usually never "reset"s
public commits - that is commits that have been pushed upstream (to Github or
what-have-you). The reason being - if someone else pulled that branch and
started working off that commit, and you reset it, it leaves the other person
in an unknown state when you do a push.

If you wish to "undo" a public commit, you should revert. If you see the
visualization you will notice that "reset" blurs out the last commit, while
"revert" creates an "anti-commit" \- that is a commit that undoes everything
the other commit did.

How can merge and rebase be trusted?

>> I am not sure what you mean by that? Do you mean will Git screw up? Or how
do you know that a git pull (which could merge or rebase) pull in commits that
have been verified?

What are the best practices for how many branches a project should have and
how & when should they be merged?

>> This is a "depends on" answer IMO.

ONE approach is that all "work" should happen on short topic branches off the
"integration" branch (which in many cases is master). Commits are made, and
things are reviewed, and tested they are merged into master.

This also means that each developer on the team merges one branch per feature
into master. Every time you are ready to merge your code into master you first
rebase master (which plays your commits on top of master) and then merge into
master.

FWIW I am giving you the 30 second answer, but this needs a detailed
explanation.

A few resources to get you started -

[http://git-scm.com/book](http://git-scm.com/book)

ftp.newartisans.com/pub/git.from.bottom.up.pdf

[http://eagain.net/articles/git-for-computer-
scientists/](http://eagain.net/articles/git-for-computer-scientists/)

Good luck!

~~~
wudf
Thanks for answering so many questions. And thank you bodhi and rcxdude as
well! I had an idea that best practices might still be an emerging topic. My
unclear question about merging was indeed about conflicts, so I'm glad to hear
that the merge philosophy is to be "stupid" as rcxdude said. I'll do some more
research and check those links.

~~~
smd4
The best resources I've found for understanding git workflows are by Vincent
Driessen[1] and Atlassian[2].

The Atlassian page is much more comprehensive, and in fact derives the
'GitFlow' workflow from Driessen. However, I prefer his original top-to-bottom
representation (a left-to-right time axis seems less intuitive to me - they
remind me of a football playbook rather than a waterfall).

[1] [http://nvie.com/posts/a-successful-git-branching-
model/](http://nvie.com/posts/a-successful-git-branching-model/) [2]
[https://www.atlassian.com/git/workflows](https://www.atlassian.com/git/workflows)

------
cfolgar
After having seen a few learn-git tools on HN and other programming forums, I
would have to say that this is my personal favorite. What this tool does
exceptionally well is teach the core git concepts from a visual point (seeing
as it's git this works very naturally) instead of asking the user to memorize
an incredibly small subset of the git commands. Often this leads to a lot of
trouble when you get into a real-world scenario that some inappropriate learn
git tutorial didn't cover. Fortunately, I think visualization tools like this
should help ;) Perhaps github could incorporate this into their Try Git page?

------
baddox
It seems cool, but I don't understand why I can't just click multiple times
instead of having to type the command several times. That UI decision makes
the site nearly unusable on an iPad.

~~~
stinos
I think I do understand: the author either did not think this was going to be
used on a tablet (after all, it teaches git in it's bare cli form, not by the
aid of an point-and-click ui) - or just didn't care about it (for pretty much
the same reason, or because he thought there aren't many people using git cli
on a tablet anyway).

------
jonalmeida
This is great, kudos to the dev!

Like others who wished they had this while teaching git, I wish I had this
while learning git.

However, the interaction seems a bit clunky - after doing a `git fetch` I
wanted to try a `git rebase` but realized I had to click on the `git rebase`
option first before typing it out. Maybe remove the need to click the option
first OR clicking it will automatically type stuff for you. Basically, it's a
two step process that once needs one.

~~~
onlywei
Thanks, I'm glad you like it.

You do not have to click the 'git rebase' option before typing it out,
actually. All of the (supported) commands can actually be used anywhere.

------
austinz
I was surprised and gratified to see that pressing 'up' in the terminal window
did exactly what I was hoping it would do.

~~~
paradite
but not tab.

------
lalos
This is great for teaching git, a nice add-on to the tool would be to add
command by command playback of custom scenarios and see them pan out. Also it
would be interesting to grab tons of different history records from
developers' shells and get common git patterns and play them back with this
tool.

~~~
zhodge
In addition to this, I think something that would help me a lot is being able
to step back and forward through any history of commands that I'm
experimenting with.

Great stuff!

------
thatnodeguy
I absolutely love D3, it's what we've been seeking for a very long time and
finally a decent product was created. Prepare to see this blow up and take
over the web soon.

~~~
ColinDabritz
D3 already underlies quite a few popular visualization libraries. While you
can use D3 directly, it's kind of a toolkit for creating visualizations, so
it's often hiding 'behind the scenes' in libraries you already know and love.

------
xtacy
Very nice, thanks for making this. I tried crazy workflows and the history
tree had multiple levels. If possible, could you add scrolling to the
visualization viewport?

------
kylebrown
Can't wait to see this working as a plug-in for Atom (github's new text
editor). Since Atom plugins are written like browser extensions (in
javascript)...

------
smd4
Nice work!

This is a great complement to the codeschool tutorial [1] it would be nice
similarly offer the feature that clicking on the command will auto-populate
the virtual terminal. New git users might be more likely to use a client-side
GUI where they are clicking buttons rather than typing in the terminal.

[1] [http://try.github.io/](http://try.github.io/)

~~~
touristtam
Oh thanks, never new that one existed. :)

------
midas007
This is a great teach aid, hits the mark.

Further, if this style of material were applied to crypto (gpg), more people
might be comfortable using it.

------
jakejake
This is fantastic. It's amazing how the right graphic can really clarify a
somewhat tricky concept like merging.

------
jdreaver
This just taught me more than any git tutorial I've read. What a great
visualization!

------
jqm
This is probably my favorite post ever on HN. Very enlightening. And, like
lots of good things.... it's simple.

As others have mentioned, it would be nice to scroll down the diagram.

But, I guess if this were really wanted, git clone would be the first step:)

------
ABS
this is pretty cool and I have been meaning to do sort of this for some time
now. I even registered a domain for it: simgity.com (a simulator for git).

Happy to "donate" it if the author is reading

------
patopop007
This is a great visualization, this should definitely be taught alongside any
existing Git tutorials. I just wish the canvas would allow scrolling, or
resize automatically.

------
tentacle
I thought the new comments rule would ban the whiners, nitpickers and nay-
sayers, but it seems all just like it was before. :O Kudos to the developer,
who made this tool.

------
specialk
I see this as a great tool for teaching the basics of git. Definitely saving
this for the next time I have to explain why branching is useful and how it
works. Great tool.

------
lucio
constructive criticism: I'm a git user, but, if you need D3 graphics to
explain a svc... can we at least accept that git concepts are not intuitive?

~~~
wambotron
We switched over to git from svn recently at work and the amount of confusion
and accidents is crazy. I've been using git (mostly solo to two coworkers) for
years, but there are still issues I run into where I'm stumped. I look things
up all the time.

You kind of need git training in cases like this. Unfortunately, we didn't
have any.

------
allengeorge
I thought this was pretty awesome :) Would be great if it were fleshed out a
little more with more complex examples. Kudos!

------
kremlin
Either something wasn't working for me, or the 'branch' function is completely
over my head.

------
jimmaswell
funny how the git push one doesn't work until you git pull, but it doesn't
tell you you have to do that, it just assumes you knew.

------
thebokehwokeh2
Can anybody suggest good D3 books?

~~~
rkda
I'm using Interactive Data Visualization for the Web by Scott Murray

[http://shop.oreilly.com/product/0636920026938.do](http://shop.oreilly.com/product/0636920026938.do)

You can read it for free at Oreilly's Chimera labs

[http://chimera.labs.oreilly.com/books/1230000000345](http://chimera.labs.oreilly.com/books/1230000000345)

------
xtc
This is great, thanks.

