I’ve been using Git as my primary version control system both at work and for personal projects for awhile now. While I think that git has become pretty widely accepted (perhaps even ubiquitous), acceptance rates seem higher among non-Windows developers. This is purely anecdotal and based only on my own experience, but it seems like a Windows developer is less likely to be comfortable using
Git than developers that work on other platforms.
I suspect this is due in part to the fact that some Windows developers don’t like using the command line (more on that later) and Git is primarily a command line tool. I also think that there isn’t much in the way of “getting started” literature out there aimed at Windows developers who want to use Git. I can’t make people love the command line (even though I try!), but I can create a Git tutorial aimed at Windows developers.
Why Should I Care About Git?
You should care about Git because it’s a good version control system. Also, if you ever want to work on an open source project the odds are pretty good that it’ll be hosted on GitHub and you’ll need at least some proficiency with Git in order to contribute to it. I also think that working with highly distributed teams (e.g. teams where all members live in different parts of the world, have different schedules, different commit habits, and varying levels of network connection quality) is going to become a lot more common in the future. Because Git is a distributed version control system (DVCS) it lends itself very well to working with these distributed teams. I’ll elaborate on the virtues of using a DVCS in a future post.
What About Other Distributed Version Control Systems?
I know git isn’t the only show in town. I have actually used Mercurial pretty extensively in the past and I really like it. That said, this post is about git. If you prefer a different DVCS and want to read a post about it, then you’ll need to find a different post to read (or write your own).
The command line? Seriously? What is this 1985?
Yes. The command line. You’re going to want to use the command line for a lot of the things that you’ll do with Git. I sprinkle in some external GUI apps here and there in my workflow where they make sense, but Git is a command line tool and you’ll need to embrace the command line if you want to use it effectively. Also, once you get used to it it’s not that bad.
If you’re a software developer the command line shouldn’t scare you.
Getting setup to use Git effectively on Windows isn’t as painless as some other version control systems, but if you follow these steps below you’ll be up and running pretty quickly.
Before we dig in here, I want to address a tool that you might feel is conspicuously absent from my instructions below: GitHub For Windows. I don’t use GitHub For Windows; not because I don’t think it’s a good tool, but because I feel like it glazes over too many of Git’s internals. I understand that the folks who built it are probably just trying to make Git really accessible to developers who haven’t used it before, but in my opinion they go a bit too far. That said, if you want to use GitHub For Windows I recommend just installing it and not following my directions below. They’ve designed that tool to be a sort of “one stop shop” for getting up and running with Git on Windows so it should be all that you need. I’ll briefly address some other good tools worth checking out at the end of this post.
If you want to work a bit closer to the bare metal of Git (and I recommend that you do), then read on:
1 – Get Chocolatey
You already use Chocolatey to install tools for your dev workstation right? If not, why not? You can find and install all of the tools I’m going to mention here without Chocolatey, but using Chocolatey will make things easier. In addition, Chocoately will encourage you to become a bit more comfortable with the command line. If you’ve never heard of Chocolatey you should read up on it here: https://chocolatey.org/about
To install Chocolatey open a PowerShell prompt as an Administrator and run the following:
iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))
You may need to re-start the prompt when you’re done. Get in the habit of running the PowerShell prompt as an administrator, since you’ll need to in order to continue using Chocolatey to install the rest of the tooling.
2 – Get Git for Windows
Next, install the git for Windows client. If you’re using Chocolatey, all you need to do is run the following at an Administrator PowerShell prompt:
choco install git
This will install git with the default options that make the sense for most Windows users. You can read more about those options on the package description page: https://chocolatey.org/packages/git
If you hate convenience and would rather install this manually, you can download and run the installer from here: http://git-scm.com/download/win
If you install git manually, be sure to choose the “Use Git from the Windows Command Prompt” option on the “Adjusting your PATH Environment” step of the install. This will put the git executable itself into your PATH variable and let you run the git commands from a PowerShell or regular Windows command prompt in any folder on your machine.
You’ll probably also want to use the “Checkout Windows-Style, Commit Unix-Style” option on the next step of the installer. I won’t go into detail on this option here, but if you’re developing on a Windows machine just go ahead and use this option.
3 – Get posh-git (Optional)
If you like using PowerShell and want to interact with git primarily through the command line interface (and you should!), then you’ll probably want to use posh-git. This set of PowerShell scripts customizes your prompt when in folder that contains a git repository and gives you an easy way to see what branch you’re currently on, if you have any pending changes, if you’re ahead or behind the default remote repository, and tab auto-completion (e.g. start typing a branch name you want to checkout and hit tab to auto-complete the name). If you’re using Chocolatey getting posh-git installed is as easy as running the following at your PowerShell prompt:
choco install poshgit
If you’re not using Chocolatey you can still get posh-git working, but it’s a bit more involved. You can find instructions in the README.MD file available on the home page for the posh-git project on GitHub: https://github.com/dahlbyk/posh-git/blob/master/readme.md
After you get posh-git setup you’ll need to restart your PowerShell prompt in order for it to be initialized. You may notice the following message: “Warning: Could not find ssh-agent”. You don’t need to worry about this for right now, but we will discuss using ssh in a later post in this series. If this message is annoying and you want to just make it go away for now, you can use the answer on this StackOverflow question to let posh-git find the ssh-agent executable:
4 – Get SourceTree (Optional)
While Git is a command line tool, you will often find yourself wanting to do things with it that are easier done with a GUI. Git for Windows does come with some rudimentary GUI tools, but there are better ones available. I’m partial to Atlassian’s SourceTree myself, but there other good ones out there. You can install SourceTree using Chocolatey with this command:
choco install sourcetree
Note: Atlassian ships updates to SourceTree pretty regularly, so the version that you’ll get from the Chocolatey package feed may not be the latest one. SourceTree will, however, automatically prompt you to update to the latest version when you run it.
The Chocolatey package will install SourceTree in a way that will let you find and run it from the Start menu. The first time you run it you’ll be prompted to accept the end-user license and be prompted to do some general configuration for things like BitBucket (their answer to GitHub) and creating SSH keys. You don’t need to do any of that for now, but we’ll talk more about that in another post in this series.
If you’d rather just download SourceTree and install it manually you can get it here:
After installing SourceTree, be sure to run it, then go to Tools -> Options. Configuration Git options is one of several things that I think is best done using a GUI tool. Be sure that the “Allow SourceTree to modify your global Git and Mercurial config files” option is checked. Then be sure to fill in the “Full Name” and “Email Address” fields in the “Default user Information” section. This information will be used any time you add commits to a Git repository. For now, the remaining options should be OK with the default values.
5 – Get git-credential-winstore
If you use Git from the command line and interact with remote repositories, you’ll quickly find that it can get annoying when you have to keep typing in your password every time you want to push or pull changes to and from the remote. Some of the 3rd party GUI tools (like SourceTree) have the ability to store credentials, but that only works if you use those tools exclusively for interacting with remotes and I usually like to use the command line interface for this type of thing.
Fortunately there are tools that make this easier. We’ll talk more in a future post about using the ‘ssh-agent’ utility mentioned in step 3 to make it easier to use SSH authentication for remote repos. For now we’ll keep things simple and rely on talking to remotes via HTTPS connections In order to do this without having to type in our password every time we want to interact with the remote, we can install the git-credential-winstore utility. This utility will give you a Windows credential dialog when you first interact with a new remote. The credentials that you enter will be stored in the built-in Windows credential store and automatically re-sent with each subsequent request.
To install this utility with Chocolatey:
choco install git-credential-winstore
If you want to install it manually and/or read more about it you can do so on the project site:
5 – Configuration
Most configuration options for Git can be set globally for all repositories, or at the individual repository level. We’ll talk about repository level configuration later, but for now you might want to set some configuration for your user. This configuration is defined in a ‘.gitconfiguration’ file that will be in your “C:\Users\<name>” folder (assuming Windows is installed on your C drive). You can open this file up with a text editor but most of the GUI tools will help you edit it. SourceTree doesn’t expose a lot of Git configuration options in its GUI, but other tools do a really good job of this (see the note about Git Extensions below).
Other Tools You Might Like
There are lots of 3rd party tools available to make your life easier with Git. The list above represents the ones that I’ve found most useful and keep coming back to. Here are a few others that you might want to check out:
- Visual Studio Tools for Git – This allows the source control functionality built-in to Visual Studio to recognize and work with projects that live in a Git repository. If you really like Team Foundation Server and are comfortable using the source control windows within Visual Studio you might like this. Personally, I prefer to just work with tools external to Visual Studio. The best feature of the Visual Studio Git tools is the automatic creation of a sensible .gitignore file when you create a new project (more on .gitignore in the next post). It’s worth noting that as of Visual Studio 2013 the Git tooling is built-in and doesn’t require a separate download and install.
- TortoiseGit – If you’re coming from SVN and use TortoiseSVN then TortoiseGit might make the transition easier. You get some Windows context-menu commands and some GUI tooling to manage repos, make commits, push/pull, etc.
- Git Extensions – I really like Git Extensions. It’s not as pretty as SourceTree, but it’s very full-featured. It can integrate with Visual Studio to give you context-menu access to file-specific info (e.g. blame and commit history) from the Solution Explorer. The best feature of Git Extensions, however, is the GUI for setting up configuration options available under the ‘Settings’ dialog. You get a nice checklist of configuration settings that you might want to set, and a nice form to change your text editing and diff tools. It’s worth installing this utility just to run through the settings one time even if you don’t use it in your day to day work with Git.
In the next post in this series we’ll talk about creating, cloning, and managing repositories for Windows development.