In the past, I’ve blathered on about the need to use a Distributed Version Control System (DVCS) for obvious reasons, while also hinting at my use of GitHub for code aimed at Operations folks. In this post, I’m taking the time to showcase how I’m using Git across a number of different systems to make coding across different locations and along side my pair programming projects easier. Plus, I already said I would on Twitter. 🙂

If you saw my vBrownBag presentation on using the Git Shell at VMworld 2015 in San Francisco, this goes a bit further into the weeds.

What the Heck is Git

As per the Git SCM description:

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

The version control piece is particularly important – it creates a relatively easy method to version the artifacts (files, code, and whatnot) contained within a repository (bucket of files related to a project). Meaning the system understands when changes are introduced, along with what the changes are. This isn’t anything particularly new, as I’ve spent many years using Microsoft TFS (Team Foundation Server) to check in and out changes. However, the difference is that Git doesn’t rely upon a master server like TFS and others do. Each endpoint (workstation, server, laptop, etc.) can be a host for repositories. Thus the term distributed is used to describe this sort of version control system.

In many cases, folks will not expose their repositories directly from their workstation. Instead, they’ll set up a remote repository on someone else’s server – typically GitHub or BitBucket. Thus, creating content, code, scripts, and so forth take place on your workstation, and then you push the changes to the remote repository on one of those hosting sites. Alternatively, you could use a private server for internal collaboration, using something like GitLab or GitHub for Enterprise.

But there’s certainly no requirement to push code to a remote host or to even share your code at all. You can use Git for local projects, too. This makes getting to know Git quite simple. When I started learning Git, I just used it on my own workstation to allow me to version control my internal projects. I later started pushing the code externally once I had the hang of things. I found that this approach limits the scope of my learning exercises, and can be less daunting for beginners.

Setup Git on Windows

I’ve used two different Git distributions: GitHub Desktop and Git for Windows. The former is more friendly to the PowerShell crowd, while the latter is a lot more *NIX like. I’ll demonstrate some screenshots below:

Installing GitHub Desktop

The GitHub installation is straight forward. Grab the bits, install them somewhere, and set up your GitHub account (even if you don’t plan to push code externally). From a configuration perspective, there are three main options to set:

1. Configure the Git global variables for your name and email address, which is important for commit signing (used to validate your changes when you send code to the public). Note that the email address used here is public.
2. The path to clone (copy) remote repositories from GitHub into your computer.
3. The default shell to use, which is PowerShell by default. If you plan to also install Git for Windows (the next section), you can change this to Git Bash if you so desire.

That’s about it.

Installing Git for Windows

One of the nice things about Git for Windows is the integration with Explorer and file extension associations. The default installation will provide contextual menu access to Git Bash and Git GUI, along with association for .git and .sh (BASH) files. As the land of Microsoft continues to give Linux a hug, this will become more important. It’s exciting to see *NIX commands on Windows. 🙂

The installer gives a few options around how to tinker with your PATH environment. This is the environmental variable that contains default paths to all of the important locations for Windows executables, PowerShell modules, etc. I’d stick with the default option Use Git from Git Bash only as a starting point.

The remaining options can be left at defaults, as there’s no reason to change them unless you’re doing something quirky.

Baby Steps with Dropbox

Now that you have Git configured, you can begin using the software to track your repositories, which are simply folders on your workstation, for changes. Before you start writing any code, I suggest using a service like Dropbox to sync your code across devices. That way you can write scripts and code that is shared across all of your devices. I use it to keep my scripts aligned across my laptops, tablets, and home office. It also protects my efforts from being lost to a drive failure and has a zero learning curve. Remember, the initial point of setting up Git is to just learn Git. Then, work your way up to using GitHub, GitLab, or Bitbucket.

To start learning Git, I have a few resources listed that are recommended:

1. Start with my vBrownBag presentation. You can find the video and slides here.
2. Use the Try Git course, which is a free online learning tool that covers the basics.
3. Code School (part of Pluralsight) has a superb Git course. It’s $29 for the month and the quality is superb.