Wednesday, December 17, 2014

Git While the Gittin' is Good

Okay, so I'm a bit late to the party, but I'm finally getting started with Git. This is something that I've been meaning to do for a really long time, but I haven't set time aside for it. The few times I've taken a brief look at it, it seemed pretty different from the source control I'm used to, and I knew that I'd have to dedicate some time to get my brain to adjust.

Although I've only been using it for a short time, I'm much more comfortable with the concepts than I was before. I think I'll be using it regularly from now on. Here's what I did to get started.

[Note: Git articles are collected here: Learning Git. And a video is also available: Git Basics for Visual Studio Developers.]

Initial Learning
First step was to learn something about Git. My initial search led me to Code School - Try Git. This gives a step-by-step introduction to basic commands. I liked this because it started at the very beginning of how to create a Git repository.

Overall there are about a dozen commands that are shown. This is an interactive experience. Each step has 3 different windows.

The description / instructions:

The command line:

The file system:

What's nice about this is that the command window is "live". So you can type whatever commands you like. In the example above, the instructions are to type "git add octocat.txt" (and you can also click the text to automatically add it to the command window). But in the command window, I typed "git status". This shows the status of the repository (with the file that needs to be added) as well as a hint message that I didn't type what I needed to complete that step.

This gives a bit of freedom to check status and list branches if you want to get some more information rather than simply mimicking the commands.

There are 25 steps altogether, including basics like adding, modifying, removing, and committing files, creating branches, and associating a local repository with a GitHub repo.

After going through this, I needed to install Git on my machine so that I could start trying it out myself. In addition, I created an account on GitHub (finally).

To download, I just went to There were a few choices to make during the installation process. I'm not quite sure if I made the right decisions (such as the defaults for line breaks). I'll figure out if I made the right choices as I get some more experience.

One of the options is to integrate it with Windows Explorer. With that in place, you get some new options in the right-click menu in file explorer. These are things like creating new repositories, opening Git command windows and even a Git GUI application. I've tried to stick with the command line -- at least until I'm comfortable with the commands.

Git will keep track of changes, branches, and history all on the local machine -- there's no need for a repository on a server. Now obviously, there are advantages and disadvantages to this. The biggest advantage is that you can commit changes, create branches, and revert to previous versions all while being off line.

I really like the idea of this because I don't live in the "always connected" world. I like to have applications that work even when I don't have a network connection. And Git definitely offers that.

The downside to having everything on the local machine is that it's not automatically backed up on a server somewhere. And that's where something like GitHub comes in. GitHub hosts your repositories (among other things) so they are somewhere other than just on your local machine. Plus, it makes it really easy to sync repositories with other machines and share your code with the public.

To create an account, just go to In addition to walking you through the process of creating an account, it also has some pretty good guidance for creating repositories -- suggesting files to add, putting in ".gitignore" files, and so forth.

And having a prebuilt ".gitignore" file is really cool. The ".gitignore" file is how you tell Git about the items that you do *not* want to be tracked. For example, in the Visual Studio world, we don't usually want anything in the "bin" or "obj" folders in our repository. GitHub has a whole bunch of files supporting different languages and environments. You can take a look at the Visual Studio file here:

This is a fairly extensive file, and people keep adding to it. In addition to the basics, it also ignores test results, ReSharper files, and many other tools files. The nice thing about this is that it is a file in a GitHub repository, so the community is involved in keeping this up-to-date (57 contributors so far).

Git Practice
One of the reasons that I wanted to explore Git and GitHub was because I had seen presenters use it in their demos -- using branches to jump to different versions of the code to show progress. Recently, a few other folks I know have been looking into this. Joe Guadagno is one of those folks. He posted a demo that has branches for each of the steps:

It's interesting to look at the branches:

This way, you can jump to a specific step, and you can also use comparison tools to see what the differences are between files.

My Repository
So, I decided to try to put together something similar. I started with my simplest demo -- showing the syntax of a lambda expression. You can see the demo in action on YouTube: Anatomy of a Lambda Expression.

This gave me a chance to create a local Git repository, add the ".gitignore", and add the initial project files. Then I did step-by-step changes to the code and committed the changes after each step. Then I figured out that I really wanted to have branches (like Joe's repo) rather than just individual commits, so I deleted the ".git" folder and started all over again.

Yep, that's right, I deleted the repo and started all over. It was really easy to do. And I was walking through established demo steps, so I didn't have any history that I needed to hang on to.

This time, I created branches as I walked through the steps. This demo is pretty simple, but it's pretty important to show each step. I ended up with 7 branches in all -- many of them only having a difference of 1 line of code.

After I got things the way I wanted them, I pushed it to GitHub. You can see the repo here:

Including all the branches:

What I Learned
I'm not sure if I'll be posting my demos like this to GitHub. But this exercise was very helpful for me. I have a much better handle on how to use Git. Here are the commands that I used in this process:
  • init
  • add
  • commit
  • status
  • log
  • branch
  • checkout
  • merge
  • push
  • remote
It wasn't a fast process, but it wasn't that difficult, either. There were times when I had to go back and look up commands or review the steps from the "Try Git" lessons. And I also had to Google some error messages. But after spending a couple hours with it, I'm pretty comfortable. I know that I still have a lot more to learn, but with the basics under my belt, I'm much more likely to use it regularly and move forward to learn the other features.

I have a system that works pretty well for me from a presentation perspective. So although I may not put everything I have on GitHub, I'll start putting my code into local Git repositories. And I can already think of a few projects that I can put online to share with other folks (like Conway's Game of Life, the rewrite of the legacy project, and the practice code analyzer).

I'm very glad I finally got around to this. Git is definitely a useful tool, and I see myself using it regularly moving forward. If you're not already using it, be sure to take a look at it to see how it can fit into your workflow.

Happy Coding!

1 comment:

  1. Jeremy,

    I realize that this is an old posting, but I felt that I had to chime in and add my two kopeks.

    1. Having used other source control processes in the past, (Subversion comes to mind), I absolutely agree that Git is the way to go. Not to mention that there is an extensive library of articles on the Web that you can search for when you need them. (That's how I ended up here!)

    2. I cannot emphasize enough how important a well designed repository(ies) is. I agree with you that people should not be afraid to dump a repository if it's not working out well. If you have work there you want to save, find the branch that has what you want, and download it.

    In my case, I had a relatively new repo on GitHub that had three branches, a master branch and two others for code and documentation. Somehow or other, they became totally un-synchronized and no amount of committing and merging could get them to the same place. Ultimately I gave up, copied the data off the repo, and nuked it.

    The bottom line is to experiment and have fun. Play with the repositories, clone them, fork them, branch them and merge them - and don't hesitate to throw them out when you need to.