Thinking in Git

I recently started using Git on a small team project. Why Git, you ask? Well, previously I had used CVS and Subversion (and by such admission I am knowingly submitting myself to being mocked by Linus), and prior to that had used Visual SourceSafe. So I figured it was time to learn something new and dive into distributed version control.

I have to say, it's a bit of a leap. In the same way that I stumbled through learning to trust in CVS to merge my changes, as opposed to locking a file the way SourceSafe did, I'm finding the distributed model takes some getting used to.

It's great that I don't have to have network access to do commits. That's the easy part to appreciate. With Git, you commit to your local repository copy. If you want to bring your changes together with someone else's, either you push to their repository, or they pull from yours, but that is in no way tied to the act of committing your changes. There's no built-in notion of a master repository. Really.

For some reason I'm finding it difficult to grasp that concept. For years I've relied on the notion that all my changes are safely locked away in the master repository. The master repository is the source of all truth. (Ha ha, get it? "Source" of all truth? You don't get it. Fine.)

In our particular team setup, we do have a master copy hosted on GitHub. I'm finding that every single time I do a "git commit", I have this unstoppable compulsion to execute a "git push", and I'm not sure that's the right idea. I'm looking forward to that breakthrough moment when I finally get it. I'll let you know when that happens.