Intermediate to advanced level git training exercises

January 25, 2016 12:31 PM

I'm looking for a set of exercises in git (the version control system) that will force me to think through resolving a difficult set of use cases. In other words, I'd like to replicate and practice fixing some scenarios one might encounter as a developer on a messy, complicated project. Can you suggest some?
posted by rhythm and booze to Computers & Internet (7 answers total)

Could you be more specific? What do you mean by "resolving a difficult set of use cases", and what are you hoping to learn?

Are you thinking about resolving merge conflicts? (That's when two lines of development modify the same file in conflicting ways, and you have to decide how to combine the changes.)
posted by bfields at 1:08 PM on January 25, 2016

Best answer: Git Immersion is a 50+ step tutorial on Git. The steps build upon themselves using a narrative of building/testing/changing/debugging a simple program. You should be able to spin through the first half really easy and then can concentrate on the more complicated parts.
posted by mmascolino at 1:36 PM on January 25, 2016 [5 favorites]

Response by poster: I am hoping to test and push my understanding of git and be better prepared for the weirder situations you can get into with git when developer discipline slips (say, during a punishing sprint that tires everyone out). I'm very comfortable with the bread and butter git commands and resolving simple merge conflicts. So something like Git Immersion is what I'm looking for. I can do the first half, but it's the second half I want to be very comfortable with. One example of what I'm looking for is this Stack Overflow question, where the poster has a repo with a detached HEAD state. The answer to this one is very detailed and even suggests a second situation to investigate (one where the detached HEAD state occurs during a rebase).

Come to think of it, it might make sense to just read through a lot of Stack Overflow questions about git and try to recreate the situations that prompted them.

Anyway, I hope this helps clarify my question. Thanks for the responses so far!
posted by rhythm and booze at 2:12 PM on January 25, 2016

Best answer: I don't have a big external list, but here are a few scenarios that have come up in the past month at my work that are somewhat hairier than standard merge conflicts:

1. Someone (I'm not saying it was me, but it was me) accidentally commits several dozen GB of large files that you didn't intend to have tracked and now every interaction you have with your repo is slow as molasses and the repo is enormous. You can "git rm" them to remove them going forward, but how do you clear them out of the history entirely? (This comes up more often in the form "oh shit, I just committed our mega-secret developer key and might have also just pushed up to GitHub", so GitHub's instructions might help.)

2. How do you amend a commit that's not the most recent one?

3. If, while trying to do (2), you accidentally do a 'reset --hard' to an earlier commit than you intended and lose some commits, how can you recover them? (This is a good way to get more familiar with "git reflog" than you might otherwise.)
posted by dorque at 3:09 PM on January 25, 2016

Best answer: I'd skip the drills and just watch the "git for computer scientists" talk if you've not already seen it (or otherwise make sure you know the data model of blobs, trees, commits cold), and learn some git commands to view and manipulate those objects. Then to move from intermediate to advanced, familiarize yourself with most every file you find under .git. So, you'll then know what the index is, where branches and tags are stored (and other refs like HEAD and the reflog too), and how objects are stored.

When you learn git from the data and files up like this, you can avoid learning a lot of detail about individual commands and options, because you can always understand the state a repository is in, and the state you want to get it to, and then it's just a matter of looking up how to get from one state to the other. Also git's own documentation, especially for more advanced commands, tends to assume this kind of knowledge.

This may be a slightly unusual method these days, but it's mostly the one I've used. Although to be fair, I picked up a certain amount of this while hacking on git and git extensions.
posted by joeyh at 6:38 PM on January 25, 2016 [6 favorites]

Best answer: Although some of it is remedial, this chapter from The Architecture of Open Source Applications gives a good overview of git's design, which will be important for understanding more unusual git workflows.
posted by dis_integration at 2:20 AM on January 26, 2016 [1 favorite]

Best answer: We've been using githug for training at work. If you've done any Git at all the first.. 5-10 levels maybe will be easy, but it ramps up quite quickly after that. It's a command line ruby gem that you install.

The thing I like about it is that it makes the files and folders within the project exhibit the problems you need to solve (rebasing, how to find out what state the repo is in etc). So you can examine your actual files, you do actually have to solve a real problem right in front of you.
posted by conkystconk at 3:04 PM on January 26, 2016