UPDATE: In March 2014, I attended an official git training by @PeterBell, hosted at Gilt! Here are my more comprehensive notes from the training: https://github.com/lpatmo/git-training-notes

Git was a bit confusing when I first started exploring it, coming from using Subversion for version control. I was used to having everything I committed go live, and the idea that everything I committed would go to some virtual staging area on my computer but not on my github account did not immediately click until… well, it clicked.

And after that, everything was fine.

(As I heard a tech conference co-attendee explain to a github beginner once, the value in not having every single thing you commit automatically be seen live by your co-workers is that it gives you room to make mistakes. You can think of a “commit” as a documented “save”/snapshot of your code. But git lets you control which commits you push to your teammates, whereas subversion does not.)

The typical commands I use when starting a new project with git:

• mkdir // Creates a directory
• git init // I type this after I cd into the directory to initialize the git directory
• [Create a repository on github.com] // All it takes is a click of a button — but this, confusingly, has to be done manually
• [Copy/paste the two commands output in the “repository created” page into my terminal] // The first set of instructions does some extra stuff that I don’t need if I already initialized the repository using git init, I believe. //

  git remote add origin https://github.com/<strong>username</strong>/<strong>repository-name</strong>.git 

  git push -u origin master

• touch index.html // This creates a file called index.html in my current directory
• pwd // Optional command that tells me where I am
• ls // This command lists the files that are in the directory. Index.html should be in here now.
• subl . // This command is configured using the sublime text editor, and opens up all the files in the directory in sublime.
• git add index.html //Adds the file so that it can be committed
• git commit index.html -m “first commit” //My first commit! If I have a couple of files ready to be committed, I can optionally type git commit . -m “first commit”. Be sure that you don’t forget the “-m” or the comment that you must type to explain the change you are documenting.
• git status //Tells me what files I’ve changed by editing and saving in the editor, and which need to be added or committed. I’ll type this often to figure out which files I’ve changed by saving in the text editor.
• git log //Tells me what my most recent commits were. Note that if I push my changes up to github.com, I’ll also be able to see my commit change logs there in a nicely visually highlighted way (green = additions; red = deletions).
• git push //Pushes up my committed files to my github.com account when I’m satisfied with my commits. I’ll do this in bursts.
• git pull // I update my local files with the commits that my teammates pushed up to the shared repository. I’ll do this before I start the day, and throughout the day.

Bug tracking ease

OH! Did I mention github’s issues/bug tracker and milestone counters? When I make a commit that resolves an issue number, I can write “resolves #87” in the commit message, and it’ll automatically close issue #87 within the repository. I found it amusing that at one point, I was using trello (a project management platform) with some hackathon friends to organize our bugs. We totally could have used github!

Yes, to be sure…

Of course, merge issues often come up, and your terminal might spit back frustrating messages such as “You do not have permission…” or “Merge conflict in FILEPATH.” I’ll discuss a few of the most common error messages I’ve encountered in another post.

But anyway… Version control FTW. I am glad I won’t be going back to drag-and-drop FTP anytime soon.