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!
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]
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
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]
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]
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
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]
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]
+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
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]
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
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
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
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]
posted by onalark at 4:04 AM on October 2, 2013 [8 favorites]
I know just enough to be extremely dangerous to myself and terrified of everything in Git
heh
heh
And then there's git rebase --interactive, which is a bit like git commit --amend hopped up on acid and holding a chainsaw - completely insane and quite dangerous but capable of exposing entirely new states of mind.posted by mikelieman at 4:49 AM on October 2, 2013 [4 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
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]
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]
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]
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
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
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]
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
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
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
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
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]
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]
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
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
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]
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
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
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
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]
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]
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
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
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]
posted by treepour at 8:06 PM on October 3, 2013 [2 favorites]
« Older Feast Days | "You are only as much as you settle for." Newer »
This thread has been archived and is closed to new comments
(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]