It's me vs. git, and git is winning

July 10, 2015 8:02 AM

I'm having a hell of a time learning git. I've read dozens of articles and tutorials, and I've made some progress...but it's been slow and agonizing, and I've only achieved a rudimentary level of competence. I'm usually pretty good about picking up new technologies, but this one has me stymied. Help?

I've spent most of my career as a lone developer, so I've never had much exposure to version control. (I have had some limited experience with SVN and TFS, but in both cases I was using them in a very basic way.)

A few months ago, I was thrown into the deep end with git: my company's main client (who accounts for 80% of our work) started using GitHub for all of the websites that we maintain for them.

After months of struggle, I've finally gotten to a point where I can make git do what I want about 95% of the time. But that remaining 5% is killing me. It throws undecipherable messages at me, and refuses to continue until I recalibrate the homeomorphic endofunctors. (And everything I try just makes things worse.) Or I do a pull, thinking that I'm just updating my local files—and git unexpectedly updates three thousand files in the remote repo. Or it suddenly decides that every single one of the tens of thousands of files in my local repo have been modified, even though they haven't. Or the bare repo with a post-update hook that I was using to deploy to my dev server—which had been working fine for weeks—suddenly starts complaining about n-dimensional Hilbert manifolds for no apparent reason.

Every time I start to think I grok what's going on, I run into a counter-example that throws my mental model of things into disarray.

And (almost) every time I work up the nerve to tiptoe a little further out, the branch (heh) snaps beneath me, and I end up falling down a four-hour rabbit hole of swearing at the terminal window. So I'm basically terrified to venture outside of the tiny little area of git that I already understand. (Learning not to venture out of the safe zone is probably the only reason I've achieved that 95% success rate.)

I've been using the command line, mostly (and it's easily the worst CLI interface I've ever encountered). I've also tried a few GUI tools—but honestly, I don't find them any easier. I can't make any sense of the branch diagrams with the colorful interlocking stripes—I mean, I think I understand what they represent, but the diagram I see in the GUI never seems to match up with what (I think) should be happening in the repo.

I suspect that most developers learn git in a situation where a functioning git workflow is already in place, and there are other, more git-knowledgeable developers around to guide them. That is not my situation—I've just been told "we're using git for everything now", and it's entirely up to me to devise and implement a workflow that supports multiple developers and multiple environments (local workstations, dev server, production server, GitHub, etc.). That's a hell of a chasm to reach across if you've never even used git before. I mean, I don't even know what a sensible git workflow looks like. It's like being asked to plan a road system when you've never driven a car.

I'm comfortable making commits to my local repo. I'm (mostly) comfortable pushing commits from my local repo to GitHub. I don't branch. I pretty much? understand what git means when it says that one repo is "X commits behind" another, but I don't really know the correct way to address that situation—so I don't really merge, either. I very quickly get lost when the subject turns to refs, reflogs, "upstream", remote tracking branches, etc. I sorta know what HEAD is, but I never touch it. I think I have a notion of what rebasing is, but I'm not even gonna touch that until I understand basic branching and merging.

I know that a git repo is a directed acyclic graph, and I (pretty much) understand what that means. I know that git is not the same thing as GitHub. I've read (most of) The Git Parable.

I think what it boils down to is this: I more-or-less understand the discrete concepts (hashes as globally unique IDs; a repo as a DAG; branching and merging; etc.) in isolation, but I can't picture how they all fit together into a complete system. It's just too much complexity to load into my brain at once. With most tools, you can learn them bit by bit, until eventually you've learned all the bits. With git, it seems like you either understand the whole complicated mess at once, or none of it makes any sense. It doesn't allow you to leave the hairier implementation details under the hood until you need them; it's all like "HERE ARE ALL THE HAIRY IMPLEMENTATION DETAILS, GOOD LUCK FIGURING OUT WHICH BOLT TO TURN LOL"

So...help? If you were once as git-moronic as I, how did you eventually get over the hump? A particular book or tutorial? A particular learning practice (e.g., setting up a GitHub repo for a personal project, as a place to experiment)? Specific "A-HA!" insights that suddenly made the murk clearer for you?

posted by escape from the potato planet to Computers & Internet (17 answers total)

Have you seen this discussion of different workflows for using git? I found it kind of helpful for getting a sense of how people use it in practice: https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow.
posted by xris at 8:15 AM on July 10, 2015 [3 favorites]

Ever tried the git branching game? I've pointed some other git-learners and have heard that it's very helpful:

Learn Git Branching
posted by Hello, Revelers! I am Captain Lavender! at 8:26 AM on July 10, 2015 [7 favorites]

Any chance you can work on-site for a week? I've taught quite a few devs to drive git, and it normally takes 2-3 hours over the course of a week. There's probably someone at the client who can teach you. I think it's much easier to be shown it than to read it.
posted by Leon at 8:27 AM on July 10, 2015 [1 favorite]

Scott Schacon's Introduction to Git talk is the gold standard to me:

https://www.youtube.com/watch?v=ZDR433b0HJY

There's some great slides somewhere, too. I'll see if I can find them.
posted by AaRdVarK at 8:28 AM on July 10, 2015 [5 favorites]

I found working on personal projects or small open source projects on github to be helpful. Some github projects ask you to rebase or squash your commits, and are willing to tell you how to do that in the specific context of your pull request.

I also found it helpful to do some pull requests and branching through GitHub's interface. All of the GUI actions line up to git actions underneath, but it was helpful to see them happen in an automated fashion first, and be able to examine the impact on my repo.

Honestly, it took me years of only using commit/push/pull/merge before I really attempted to understand what what going on. I had the luxury of stepping into an existing workflow, which helped a lot. Contributing small changes to small/welcoming OSS projects could be a way for you to get some of that same experience.

This is possibly unorthodox, but I found it very eye-opening to attempt to build a version control system from scratch (where the target system is similar to git). Thinking about versioning files and getting both sides to agree on one current version & history helped me a lot.

While mercurial is not git, they are related, and this introduction to mercurial helped me a lot: Hg Init.
posted by triscuit at 8:34 AM on July 10, 2015

It sounds to me like you've run into a lot of different problems, and you believe all of them stem from a fundamental lack of understanding of the underlying git model.

Which may be true to some degree, but I wonder if you wouldn't feel more progress from just making a list and checking off one problem at a time. So for example:

"But that remaining 5% is killing me. It throws undecipherable messages at me, and refuses to continue until I recalibrate the homeomorphic endofunctors."

What exactly is an example of such an error? Can you reproduce it on a toy repo? Could you ask about it here or in some other appropriate forum?

It's true, I do feel like git is built out of a small number of underlying ideas which, once you understand them, make everything easier. But personally I arrived at that understanding by fooling around a lot, making some mistakes, asking questions, and realizing "oh, so *that's* what they meant about the index", or whatever.

But of course you've probably already done some of that.

I don't know, it sounds honestly like you're honestly pretty close. You've got some of the basic ideas and you've got motivation and a project to accomplish--it'll all make more sense soon....
posted by bfields at 8:37 AM on July 10, 2015 [1 favorite]

I suspect the answer may be to branch more. (I'm a git neophyte). It's pretty clear that the endofunctors term is a wretched joke, not sure where it's inserted, I searched the source and ran strings on the git binary and didn't see the term.

Remember git was designed for the linux core dev effort. A strongly monitored established base with a bajillion potential distributed contributors. Look for a pattern of use where a workflow functions and follow that basic approach. If someone is trying to mold git into a shape where it's not going to fit I'd expect pain.
posted by sammyo at 8:39 AM on July 10, 2015 [1 favorite]

But from various bits around the web I suspect just about everyone using git nontrivially gets wacky situations that take unreasonable effort to unwind.
posted by sammyo at 8:43 AM on July 10, 2015

So, I hate pull. 'git pull' is a terrible, deceptive way of using git, and I hate that it's the default everybody learns when they start using git. It does too much stuff under the hood and it encourages you to use it as a magical crutch that just "updates" the branch. Learn about 'git fetch' and forget about 'pull'. As soon as I started using the fetch commands for everything, my git flow suddenly made a lot more sense to me. I would link to some docs for git fetch but I'm sure you can find it yourself.

The other thing that's good to learn about is 'git reflog'. I say this because it's easy with source control systems to panic and think you lost some commit during a tricky merge operation. In git, it is almost impossible to lose commits, because they'll always show up in the reflog (unless you run gc, which you should almost never do). So even if you totally screw up your local environment while learning the ins and outs of git, you aren't going to lose work. Knowing this makes me a lot more confident when doing something tricky in git.
posted by deathpanels at 8:43 AM on July 10, 2015 [7 favorites]

Well, I think there will always be more Git to learn for most of us. But getting to adequate is doable. I agree with others that you're not that far out.

This isn't a h4rdcor3 answer, but you might try a GUI tool that works with Git. I've used SmartGit and a) it does provide a friendlier layer over all the arcana, and b) having your diff tool integrated with your VCS is really really nice. Very easy to survey and/or dig into what the other dude did during your off hours.

In any case, GUI or command line, you need to learn branching and merging. That is an essential piece that you can't ignore. If you're having trouble with branching, don't try to learn it on real code. Set up a separate local repo and practice making (tiny) feature branches and merging them. Be sure to deliberately set up some merge conflicts while you're practicing. Branching should make sense with a little practice--the basics are not that hard--but you need to practice without feeling like you're going to lose your work or screw up your repo.
posted by mattu at 8:54 AM on July 10, 2015 [2 favorites]

Response by poster: Thanks, AaRdVarK—that videos helps a lot. I doubt it would make much sense to me if I didn't already have some background with the concepts, but it really helps to see exactly how different commands affect the graph. (If anyone else watches it, be prepared to pause and rewind a lot—he talks really fast. But there's a lot of good info in there.)
posted by escape from the potato planet at 11:55 AM on July 10, 2015

I learned a lot from the book Pro Git.
posted by Pronoiac at 9:47 PM on July 10, 2015

Every git story I've heard - including my own experience - is that you bash on it for awhile and then the light comes on and you totally git it (hardehardehar). I'd agree that working on a personal project, especially with a collaborator helps a ton.
posted by bendy at 10:45 PM on July 10, 2015

what worked for me was to google stackoverflow if i bungled something. invariably someone had a solution and enough bungling gives you enough ideas how you can get out of a situation. Some teams use some complex workflows others more simple. my current team develops on branches then merges master into the branch then merges to master once complete. the git graph looks messy but it works and it is simple without a lot of cognitive overhead. some teams prefer to have a master and development branch and tag releases as well as rebasing so their graph is linear. maybe spend some time working on a local repo with the command line or a gui client doing common stuff add, commit merge branch revert to previous commit create a remote branch etc
posted by andendau at 11:38 PM on July 10, 2015

Viewers may also be interested in git for ages 4 and up.
posted by pwnguin at 5:39 PM on July 11, 2015

> my current team develops on branches then merges master into the branch then merges to master once complete.

You should look at rebase. Same amount of work for a neater (IMO) graph.
posted by Leon at 1:52 AM on July 12, 2015 [1 favorite]

I don't know if SourceTree was one of the clients you used, but I learned the basics (branching, committing, merging, occasionally reverting a commit where I've messed something up) doing that with a tiny bit of command line, mostly for the reverting stuff, and it was fine. I really liked how easy and clear it was to see your diffs pile up as you're working. The one mantra I'd repeat when I was getting scared was "It's really hard to permanently fuck things up here, unless you push." So I'd basically play around freely in my local repo, but would be very careful that everything looked good before pushing anything.
posted by Aizkolari at 2:47 PM on July 13, 2015