Learn Git branching interactively!
October 1, 2013 10:27 PM   Subscribe

If you think of Git as "fun," you can play this fun Git branching tutorial game!
posted by Nomyte (40 comments total) 87 users marked this as a favorite
 
This would be even better if the guide windows were movable!

(Why yes, I've been playing a lot of Papers, Please. Why do you ask?)
posted by lumensimus at 10:30 PM on October 1, 2013 [2 favorites]


Now all I have to do is figure out what Git is.
posted by zardoz at 10:32 PM on October 1, 2013 [1 favorite]


Then again, I always used Git Extensions, so a lot of this, while not exactly new, was at least somewhat obscured by GUI abstractions.
posted by lumensimus at 10:37 PM on October 1, 2013


Well, I've been trying to learn by the "holy crap did git REALLY just eat all of my work?!? halp!" method and it hasn't worked very well. I know just enough to be extremely dangerous to myself and terrified of everything in Git, so maybe this will help.
posted by treepour at 10:37 PM on October 1, 2013 [5 favorites]


zip -9r bkup.zip .git
posted by RobotVoodooPower at 10:43 PM on October 1, 2013 [1 favorite]


This is just what I needed to help me teach git branch management to my coworkers, thanks!
posted by Fruny at 10:45 PM on October 1, 2013


Most Git stuff is pretty command line focused but I've found the UIs of both GIT hub and SourceTree pretty handy for giving me a good grasp on what's going on.

Branching is actually one of the least painful areas of Git, especially compared with some other source control methods - in VSS or Perforce it can be a major deal to branch and merge and soak up a bunch of time, in Git you'll find yourself doing it daily as a matter of course.
posted by Artw at 10:46 PM on October 1, 2013 [2 favorites]


Very slick interactive rebase. This is fun.
posted by bbuda at 11:52 PM on October 1, 2013


+1 for SourceTree

I'm a relative Git newb, but source tree makes it all pretty easy for the routine stuff
posted by johnstein at 12:15 AM on October 2, 2013


This is awesome! As a git/bitbucket team, this could help the entire team catch up!
posted by greenhornet at 1:54 AM on October 2, 2013 [2 favorites]


Nthing Sourcetree. When helping a coworker out with it, though, I learned there are some idiosyncratic differences between the Mac and Windows versions, but maybe they've been fixed by now.
posted by ardgedee at 3:37 AM on October 2, 2013


Now Sourcetree ought to work on adding svn support because the GUI svn client options for Mac range from mediocre to worse.
posted by ardgedee at 3:38 AM on October 2, 2013


I only just get by with git, so thank you. This is good for me. Maybe I'll figure out what rebasing is.
posted by zoo at 3:56 AM on October 2, 2013


I teach a fair amount of Git to scientists as part of my volunteer work with Software Carpentry. I'm actually not a big fan of this website, and I still need to write up a good tutorial. I really like Scott Chacon's Pro Git book, and I think for truly understanding Git the best thing to do is to try and understand the Visual Git Reference by Mark Lodato.
posted by onalark at 4:04 AM on October 2, 2013 [8 favorites]




Git is just magic for working with other people, and I use it for all of my personal projects too because it's so handy (and when it comes to coding, I consider "me-now" to be a different person to "me-in-a-week" anyway). But to a newcomer it is a bit like playing a text adventure rogue-like where if you die all of your work gets put in a chest on the next level down.

This looks like a great way to get a feel for what on Earth is actually going on when you do things on the command line, and I think learning that is ultimately way more demystifying than using a GUI.
posted by lucidium at 6:26 AM on October 2, 2013


Oh, cool, thanks onalark & mikeliemanm, those are great, the two comments should go on the special git sidebar.

Now, no, really, shouldn't the MiFi db be converted to git so that all the deleted comments, dup posts, snark and revisions can be rebased whenever the subtle cultural changes occur, also, think cross post threads.
posted by sammyo at 6:28 AM on October 2, 2013 [1 favorite]


I've been using git almost daily for a few years. I really like the concept of this game, and it shows off the tree, and navigating therein, really well. I think being able to visualize the tree (combined with awareness of some of the more esoteric git commands and good google-fu) is critical for getting yourself out of tricky git situations, especially if you want something shareable and not too convoluted. I like that the game emphasizes that commits are replaced, not modified, and that your original work is still OUT THERE, just not necessarily reachable.

That being said, this game focuses a whole lot on things that modify history (IOW, any time a commit with a ' mark shows up, which is a lot in later levels), and if you're doing any sort of collaboration (like pushing to github or similar regularly), you need to be really wary of commands that rewrite history (e.g., rebase, cherry-pick, reset). 'git merge' and 'git revert' are mentioned in this tutorial briefly, then never again, but those two tools are how you manage history, undo work, and bring in new features to your work while still keeping your tree shareable.

Now maybe you do a lot of code reordering/tweaking locally before you push, or maybe you do a bunch of commits, then pretty them up (amending commit messages, squashing, etc.) before pushing. That's where a lot of these commands are really helpful to know.

BUT, be aware if you're using this as a method for learning how to wrangle git with any sort of code sharing, you need to treat most of the techniques here with caution. I strongly second the recommendation for Pro Git, and would throw git ready into the mix as well (older content, but still relevant).

(That's not to say I don't think this is excellent; git-as-game makes a lot of sense, especially when there are so many ways to reach a goal state in git.)

(Oh, and everyone should know about git pull with rebase, which is really handy for avoiding unnecessary merge commits when you bring in new work from a remote)
posted by Vendar at 7:31 AM on October 2, 2013 [4 favorites]


Right Click -> Clone
Right Click -> Commit
Right Click -> Push

Not so hard now, is it?
posted by blue_beetle at 7:38 AM on October 2, 2013 [1 favorite]


Please someone make me one of these things of Mercurial. I use git all the time and am happy until every now and then I encounter a project that uses mercurial and I'm able to stumble through it. I want to be more fluent in mercurial, but I encounter these projects too infrequently.
posted by Galaxor Nebulon at 7:41 AM on October 2, 2013


Wow, what a neat tutorial, it tells you pretty much everything you need to know except whatever the hell Git actually is.
posted by Mooseli at 8:10 AM on October 2, 2013


> Please someone make me one of these things of Mercurial. I use git all the time and am happy until every now and then I encounter a project that uses mercurial and I'm able to stumble through it. I want to be more fluent in mercurial, but I encounter these projects too infrequently.

Make sure you have git-remote-hg in an appropriate place in your PATH and then do:

git clone hg::/path/to/mercurial/repo/

And stop using hg for anything.
posted by atbash at 8:14 AM on October 2, 2013 [2 favorites]


Psh. My git tutorial was having coworkers spend a couple days undoing a botched hotfix merge.
posted by spamguy at 8:33 AM on October 2, 2013


Is there anything like SourceTree for Linux? (By that, I mean something of comparable UI design quality.)
posted by Blazecock Pileon at 8:57 AM on October 2, 2013


My experience is that there are a ton of little tools each of which will handle part of the process, and all else is dealt with by asking why you aren't using the command line as god intended.
posted by Artw at 9:02 AM on October 2, 2013


Thanks to Git, I earned a pup tent and a chopper bicycle.
posted by Flashman at 9:04 AM on October 2, 2013


I had a nice comment for this thread, but when I tried to post, I got a conflict, so I had to stash what I had, reload the page, re-scroll down to the bottom, stash pop, and post it again. It looks correct in my browser, but can someone tell me if it actually got pushed ("mefi diff origin/master master" doesn't show anything, but I don't trust it anymore)
posted by kurumi at 9:11 AM on October 2, 2013 [7 favorites]


That's where my comment early, comment often strategy comes into play.
posted by Artw at 9:27 AM on October 2, 2013 [1 favorite]


Galaxor Nebulon: Have you seen This?. It's not interactive, but it's friendly.
posted by zoo at 9:50 AM on October 2, 2013


zoo: Ooh, I'll check that out. But I will probably use atbash's solution instead, and never have to learn mercurial.
posted by Galaxor Nebulon at 10:08 AM on October 2, 2013


Can anyone explain why it's so damn impossible to find a very simple introduction to what git is and how it works conceptually?

I swear, every single 'tutorial' assumes at least some knowledge of how it all operates. Starting with "oh, this is used for tracking and organizing code" gets you nowhere.
posted by graphnerd at 10:38 AM on October 2, 2013 [1 favorite]


kurumi: you should always fetch before diffing a remote (fetch just updates remote refs, does not change anything in your local branches).

In other words: try hitting f5 to refresh.

Graphnerd the intro to the linked site did pretty well I thought. It tracks the history of your project, and allows you to navigate through that history. The missing key is that this is most useful when two or more people are working in parallel.

The big breakthrough with git as opposed to most other source control coming before it historically is that every copy of the project is a fork. So you need to explicitly update your views of the upstream data, and explicitly integrate everyone's work. This is actually an improvement, and once you adopt the conceptual model, it is simpler than pretending there is one canonical state of things existing on many computers at once.
posted by idiopath at 10:47 AM on October 2, 2013


graphnerd: I'm assuming you know what "version control" is and why you would want to use it.

As for Git specifically, you have an apt username, since Git is a directed acyclic graph of patches from one commit to the next. And each commit's ID is a hash of the current patch, the commit message, and the last commit's hash.

The reason that's important is that if two commits have the same hash, they are guaranteed to have the same history behind them, which is what lets Git be able to push and pull between repositories.

Not sure if that helps or not :-)
posted by karlshea at 11:00 AM on October 2, 2013


graphnerd: Because most people blindly ignore implementation details, and just start with a cheat-sheet of commands without understanding the plumbing.

That said, the Git Internals chapter is rather informative, and might be what you're looking for.
posted by fragmede at 12:50 PM on October 2, 2013


graphnerd:
For a really basic, start from the very beginning tutorial, see Git Magic
posted by notbuddha at 1:22 PM on October 2, 2013 [1 favorite]


Can anyone explain why it's so damn impossible to find a very simple introduction to what git is and how it works conceptually?

As it happens, Understanding Git Conceptually is my favorite intro to git.
posted by twirlip at 1:43 PM on October 2, 2013 [2 favorites]


I'm with you graphnerd, but I'm glad everyone has come down on your with answers, because I might figure it out now too. I even asked MeFi and got some answers, but I still haven't figured out how to turn my six "forks" (one for each customer) into one 'git'.
posted by AzraelBrown at 2:16 PM on October 2, 2013


graphnerd: Can anyone explain why it's so damn impossible to find a very simple introduction to what git is and how it works conceptually?

The reason simple guides to how git works conceptually aren't common is that the internals are actually pretty simple and elegant and when people find out about them they want to share. Unfortunately this is not particularly helpful and (reasonably) causes many people to tune out. Git Magic (which notbudda linked) avoids this trap.

Starting with "oh, this is used for tracking and organizing code" gets you nowhere.

If you aren't interested in tracking and organizing code why do you think you need git? Though it can be used for other things tracking code is the intended and most common use, and if that's not what you're doing it may not be a good fit.

AzraelBrown, your "forks" should be "branches" in version control software. In the typical case there's one "base" branch that's vanilla and the other versions would be derived from it; you don't have to do it that way, but since that's a common way to do it that's the way most guides will describe.

In git the way you could maintain your separate branches is called "cherry-picking", which allows you to apply single commits from one branch to another. Like notbuddha I recommend Git Magic, which makes a point of not discussing implementation details except in an optional chapter at the end. The chapter I got back to in particular is the one on branching, which mentions cherry-picking. Here is a very straightforward, very short guide to cherry-picking specifically.
posted by 23 at 7:10 PM on October 2, 2013


Just coming back here to say I've been using SourceTree for a couple of days now and, so far, it's a dream come true. Many thanks to everyone who recommended it!
posted by treepour at 8:06 PM on October 3, 2013 [2 favorites]


See also Code Combat and Core War.
posted by jeffburdges at 8:31 AM on October 24, 2013


« Older Feast Days   |   "You are only as much as you settle for." Newer »


This thread has been archived and is closed to new comments