Getting to Commit to Git

I'm going to assume that if you're here, you have both a current version of Eclipse (Kepler!) and a GitHub account. But I'm also going to assume you haven't really done this before. I sure hadn't, and I had a few headaches. Let's begin the adventure...

Tools for Learning Git

Basic Terms

You'll need to know some basic terms before you can talk about Git—or really, any SCM system.

• Repository and Workspace: A workspace is where you edit and modify your code. A Repository is where it's stored in the long-term. It's sort of like growing and pruning a potted plant before moving and planting it in your garden—except 
• Committing: When you feel good enough about your work that you save your changes to a code repository, and not in your workspace (sometimes also called a sandbox). Some companies let only certain people, those in charge, commit. This makes it easier to keep code from branching.
• Branching and Merging: When you 'branch off' from the main group and start doing work on your own. Merging is when you take that branch, compare it to the main code, and consolidate the differences back together. Commonly seen as a bad idea and painful process (respectively) with most version-control systems, Git takes a contrarian approach (or what its creators might call "the right approach") by making branching as friendly as possible to encourage better workflow.

Talks About Git

After much headache trying to just guess and Google (which can work if you are deft at browsing Stack Overflow questions, but not so much if you want a straight-up and thorough explanation) I decided to try and do it right. I started browsing until eventually, I found paydirt:

The above talk is Git (and Linux) creator Linus Torvalds, presenting on why Git is superior to everything in the known universe. Torvalds has an interesting and sharp presentation style, but his explanations (especially about the nature of "truly distributed SCMs") are great.

When you want to learn about a subject—how to talk about it and use its jargon, it's always very useful to hear an expert discuss the ideas behind it. Usually you can get a clear idea of the nature of the subject, which is just as important as the information.

UPDATE: The four introductory videos found on the Git website are also really great to watch, especially for beginners.

The Book

I'm a book man myself, and so I ordered Pro Git. I highly recommend it, if you're the type of person who loves physically marking textbooks up, highlighting, writing notes, and putting stickies in. If not, just use the free online documentation, which is the same thing.

Both are full of very useful diagrams and thorough, plain-English explanations. Of course there is a lot jargon, but it's all introduced very clearly before being used. I recommend reading it cover to cover.

Diagrams

Probably the most useful, for reference. After a quick search, I took a liking to this workflow diagram in particular, for its succinctness.

I'm personally using EGit so I don't input these commands in particular, but it's always good to know what's going on under the hood.

Interesting note: the above workflow is from a Software Carpentry opinion piece that compares Git to Subversion in a fairly negative way. I actually also recommend reading this (and the commented replies) to get a good discussion about complexity vs. complicatedness.

Git is very complex (harder to learn), but can help keep projects from getting complicated once you understand it. Subversion is not so complex (much easier to learn), but some people think it makes it easy for projects to get complicated by bad branching and the like.

Backstory

This all started when I began thinking of a way to re-familiarize myself with the many core concepts of programming and computer science. While I was playing Dungeons & Dragons with my friends, I was wondering what sorts of programs I might make as a self-reintroduction. Can you guess how the story ends?

Enter what is currently being called D-and-D, a class interface which will eventually be coupled with a nice Android GUI to make for a smooth D&D 3.5e experience. I knew a friend who wanted to work with me, so we got to planning and coding.

And that's when we started to wonder how we could keep our source code in sync.

I had remembered hearing from Jade Rubick at New Relic, who was kind enough to give me an informal informational interview one serendipitous day, that if I had a GitHub account with a few projects, to which I committed something about every day, I could pretty much guarantee myself a job.

So needless to say I made myself an account shortly afterwards, and got to work brainstorming project ideas like D-and-D. And it wasn't until I got to actually coding that I started to realize just how complex Git really is.

But I knew it was an industry standard, or at least something which looks good to a potential employer, so I kept pounding my head against it. And slowly I've started to understand the system.

Thanks for reading. I'm touched that you bothered to read this section.