7 ms·

Visualizing Git Concepts with D3.js

346 points by sebg 13y ago

specialk 13y ago
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.
allengeorge 13y ago
I thought this was pretty awesome :) Would be great if it were fleshed out a little more with more complex examples. Kudos!
pdq 13y ago
See also "Learn Git Branching": http://pcottle.github.io/learnGitBranching/?demo http://pcottle.github.io/learnGitBranching/?demo
- ChuckMcM 13y ago
  That is pretty cool.
- ColdHawaiian 13y ago
  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 13y ago
    That's exactly what I was just thinking I wished existed!
  - deleted 13y ago
    [deleted]
jakejake 13y ago
This is fantastic. It's amazing how the right graphic can really clarify a somewhat tricky concept like merging.
lalos 13y ago
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 13y ago
  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!
xtc 13y ago
This is great, thanks.
robbles 13y ago
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.
- scrollaway 13y ago
  Purely anecdotal feedback coming up. This is somewhat old (like at least a year old I think). I've been using git for a pretty long time but as my main usage was on solo projects I was not at all making use of branches, rebasing and so on. I knew the concepts though but the entire thing was still a mix grey cloud for me up until a few months ago; even though I've had previous experience dealing with git internals (libgit and libgit2). I saw this site before and I thought it was very cool but it was not teaching me anything new. Although everything seems clear and simple, it is a representation I simply could not wrap my head around. It's like when you learn a new language: I know "libro" means "book" in spanish but I cannot associate it with the concept of a book, until I move to spain and speak the language. Then I got my new job. New git workflow and I had to use branches and rebasing in the field on an hourly basis. And ever since, everything clicked. Now that I see this link again, it is not only clear, it feels like I speak the language. All in all, I think this is a great piece of work, but pedagogically speaking, I think of it more as a visual cue to pair with the git actions when you do them than something to rely on.
- Gazler 13y ago
  Excuse the self promotion I wrote a tool aimed at teaching git at https://github.com/Gazler/githug https://github.com/Gazler/githug
  - touristtam 13y ago
    ok, I need to download && install just to see a demo? Maybe you should create a demo page.
thatnodeguy 13y ago
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 13y ago
  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.
cfolgar 13y ago
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?
austinz 13y ago
I was surprised and gratified to see that pressing 'up' in the terminal window did exactly what I was hoping it would do.
- paradite 13y ago
  but not tab.
jimmaswell 13y ago
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.
jonalmeida 13y ago
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 13y ago
  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.
xtacy 13y ago
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?
jdreaver 13y ago
This just taught me more than any git tutorial I've read. What a great visualization!
patopop007 13y ago
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.
midas007 13y ago
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.
wudf 13y ago
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 13y ago
  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!
ABS 13y ago
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
smd4 13y ago
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 13y ago
  Oh thanks, never new that one existed. :)
thebokehwokeh2 13y ago
Can anybody suggest good D3 books?
- rkda 13y ago
  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
baddox 13y ago
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 13y ago
  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).
kremlin 13y ago
Either something wasn't working for me, or the 'branch' function is completely over my head.
kylebrown 13y ago
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)...
lucio 13y ago
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 13y ago
  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.
- ColdHawaiian 13y ago
  May I ask what it is about git concepts that you find un-intuitive? To me personally, git makes a lot of sense conceptually, although the use cases of some commands can be a little confusing at first (e.g. `git checkout` for both switching branches and undoing changes to a dirty working copy).
- dcre 13y ago
  Oh, absolutely. I have yet to meet someone who didn't take several months to feel comfortable with it.
tentacle 13y ago
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.
jqm 13y ago
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:)

346 points by sebg 13y ago

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.

allengeorge 13y ago

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

pdq 13y ago

See also "Learn Git Branching": http://pcottle.github.io/learnGitBranching/?demo http://pcottle.github.io/learnGitBranching/?demo

ChuckMcM 13y ago
That is pretty cool.
ColdHawaiian 13y ago
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 13y ago
  That's exactly what I was just thinking I wished existed!
- deleted 13y ago
  [deleted]

jakejake 13y ago

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

lalos 13y ago

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 13y ago
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!

xtc 13y ago

This is great, thanks.

robbles 13y ago

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.

scrollaway 13y ago
Purely anecdotal feedback coming up. This is somewhat old (like at least a year old I think). I've been using git for a pretty long time but as my main usage was on solo projects I was not at all making use of branches, rebasing and so on. I knew the concepts though but the entire thing was still a mix grey cloud for me up until a few months ago; even though I've had previous experience dealing with git internals (libgit and libgit2). I saw this site before and I thought it was very cool but it was not teaching me anything new. Although everything seems clear and simple, it is a representation I simply could not wrap my head around. It's like when you learn a new language: I know "libro" means "book" in spanish but I cannot associate it with the concept of a book, until I move to spain and speak the language. Then I got my new job. New git workflow and I had to use branches and rebasing in the field on an hourly basis. And ever since, everything clicked. Now that I see this link again, it is not only clear, it feels like I speak the language. All in all, I think this is a great piece of work, but pedagogically speaking, I think of it more as a visual cue to pair with the git actions when you do them than something to rely on.
Gazler 13y ago
Excuse the self promotion I wrote a tool aimed at teaching git at https://github.com/Gazler/githug https://github.com/Gazler/githug
- touristtam 13y ago
  ok, I need to download && install just to see a demo? Maybe you should create a demo page.

thatnodeguy 13y ago

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 13y ago
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.

cfolgar 13y ago

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?

austinz 13y ago

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

paradite 13y ago
but not tab.

jimmaswell 13y ago

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.

jonalmeida 13y ago

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 13y ago
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.

xtacy 13y ago

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?

jdreaver 13y ago

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

patopop007 13y ago

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.

midas007 13y ago

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.

wudf 13y ago

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 13y ago
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!

ABS 13y ago

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

smd4 13y ago

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 13y ago
Oh thanks, never new that one existed. :)

thebokehwokeh2 13y ago

Can anybody suggest good D3 books?

rkda 13y ago
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

baddox 13y ago

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 13y ago
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).

kremlin 13y ago

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

kylebrown 13y ago

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

lucio 13y ago

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 13y ago
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.
ColdHawaiian 13y ago
May I ask what it is about git concepts that you find un-intuitive? To me personally, git makes a lot of sense conceptually, although the use cases of some commands can be a little confusing at first (e.g. `git checkout` for both switching branches and undoing changes to a dirty working copy).
dcre 13y ago
Oh, absolutely. I have yet to meet someone who didn't take several months to feel comfortable with it.

tentacle 13y ago

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.

jqm 13y ago

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:)