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

• 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) http://tom.preston-werner.com/2009/05/19/the-git-parable.html. 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?

• Answer:

  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.