Simple Guide to Git for Windows

Coming from a pure Windows background (with experience using DOS), and trying to make sense of version control for the first time in my life, getting started with git wasn’t easy. To start off with, it’s mostly command line based. That’s not a drawback as such, but it means you have to mess around with environment variables, typing in the names of folders to get to where you want etc. It’s a pain. In this article, i’ll explain how to get around all that and still use the command line on Windows.

Also a lot of terms used in git guides assume you know stuff – like what the hell is a “git bash”? Then you’ll hear things like “Powershell”, “Msysgit” etc which can confuse you all over again. Let’s take it from the beginning and go from there.

Installing Git on Windows

Go to git-scm.com and install the git for Windows package. Along the way, you’ll be asked to choose how you want to use git. At one choice screen, select the context menu with Git Bash and Git GUI. Then you’ll get the following screen where I’ve chosen the very first option:

Git is a program just like any other. As a DOS user, you know that if you run a command from the C:\> prompt without adding it to your environment variables, you’ll get a message saying “‘git’ is not recognized as an internal or external command, operable program or batch file.” But I’ve never liked adding environment variables to my PATH locations. Because if I uninstall programs, they still remain there. Even if I change their locations, I have to manually remove the old environment variables. Too messy for me. So we’ll be using Git only with Git Bash.

Also when asked in another dialog, choose to make git bash show up in the context menu when you right click a windows folder.

What is “git bash”? Turns out it’s just a command line interface. I have no idea why they can’t just call it “Git cli” or “Git commands”. “Git bash” is a pretty lousy name, but that’s what it is!

How and WHERE to Run Git

Git tracks files in a folder. Any kind of files in a folder and its subfolders. So you don’t need to have any particular directory structure or any particular file type for it to work. Say you have a project stored in C:\My Project. The project structure is like this:

C:\My Project>

…sourcefile1.java
…sourcefile2.c
…[bin] (folder)
…blah blah blah

We need to run git inside the “My Project” folder. But sincewe  haven’t added git to the Windows environment PATH variables, we can’t just navigate to C:\My Project> in  a DOS prompt and type in the “git” command. And besides, didn’t I say I don’t like navigating folders via DOS anyway?

So fire up the regular Windows file manager and go into your “My Project” folder. Right click on an empty space in the Window, and select “Git Bash” like in the following screenshot:

This will open a command prompt that’s already in the folder you want. To make matters easier, the path doesn’t appear on the same line on which you type your commands like with the DOS prompt. This means you have the entire line to write your stuff without having it crowded out by a possibly long list of directories which you don’t need. It’s convenient!

There’s also a “$” prompt under the path instead of the familiar “:\>” that we see in Windows. This means it’s trying to emulate a Unix environment. Don’t know why it has to do that, but there it is. No big deal. If you want to list all the files in the directory you have to type “ls” instead of “dir”. If you want to clear the screen, you have to type “clear” instead of “cls”. Here’s what it looks like:

Running Git to Track your Project

Now that you’ve opened git bash inside your project folder, you can start tracking the files inside. Git stores its data in something called a “repository”. It’s a hidden folder called “.git” that sits in the root of your project folder. It’s created for the first time when you type:

git init

Try it and check to see if the folder has appeared. Next, we want to “stage” all our existing files and folders preparing to commit to the git repository for the first time. To do this, type in:

git add -A

There are a bunch of options we can use. “-A” simply “stages” all files and folders that have changed since last time. Since the repository started out empty, this includes everything.

But wait! Git has an odd system where “git add” merely prepares (stages) the files for being finally pushed into the repository.  Type:

git status

Reading this will show you that the files in green are “staged” and ready to be committed. Presumably this system allows users to review what changes they want committed to git’s repository before they actually go in. It’s an additional step that I’m not sure is necessary, but there it is. To actually insert (commit) the files we just staged using “git add -A”, we need to type:

git commit -m “Enter message here. This is necessary”

This is where all the magic happens. First we had “git add -A” to stage all changed files and folders inside the project directory. The we had “git commit” to finalize those changes and store them in the repository. Every time your content changes, update the git repository by chaining together  “git add -A” and “git commit” the way we just did. Use “git status” regularly to see the current situation. Files in red mean that the changed files are not “staged” and need to be included with “git add”. Green files are staged and ready to be committed with the latest changes.

Keep in mind that all this is still on your local system. It’s a backup to be sure, but if your hard disk crashes you’re screwed. What you need is a remote git repository that you can “push” your local one to. So that’s what we look at next.

Getting a Remote Git Repository

Two of the most well known free services are Google Code and Github. Though it can be any location – even another folder on your computer if you want. This makes it easy to let your Dropbox or Google Drive folder be your remote repository since whatever’s in there will get backed up to the cloud anyway.

For some reason, I prefer to use Google Code since I haven’t really worked with Github. I may try it out one of these days. So go to http://code.google.com/ and click “Create a new project”. Enter your project details and choose Git as the version control system. Once all that’s set up, we need three things to push our local git repository to the remote one:

1. Project URL on Google Code

2. Username

3. Password

This password isn’t the same as your Google login password. Let’s get the URL first. Go to the “Source” tab of your new project and under option 1, you’ll see the URL with your username attached to it like so: https://username@code.google.com/p/project-name/. If you remove the “username@” part, you’re left with the pure URL of your project. As for the password, there’s a link under option 1 that takes you to a page showing your password. To incorporate both the username and password into your URL, merge them like this: https://username:password@code.google.com/p/project-name/

Hosting your project on Google Code makes it open source automatically. That means anyone can get a copy (clone) of your public repository. To do that, they don’t need your password. But you will need the password to push changes from your local computer onto Google Code. In other words, only those with the password have “write” privileges to your repository. It makes sense.

First we need to tell Git to store the address of the remote repository. You don’t want to go around typing the URL and username/password each and every time you push your changes. So I use the following command to create a shortcut to the URL:

git remote add googlecode https://username:password@code.google.com/p/project-name/

The “remote add” command tells git that for all future references to this URL, we can can use “googlecode” as a shorthand instead. Don’t forget to type in your username and password! If you just use the URL with only the username as shown in the “source” tab, git will assume the password is nothing when you finally try your push – which of course it isn’t. And you’ll get the following error:

fatal: remote error: Invalid username/password.
You may need to use your generated googlecode.com password; see https://code.google.com/hosting/settings

You can even use the pure URL with neither the username nor the password (No “@” symbol at all) and git will then ask you to enter your username and password manually when you try and make changes to the remote repository.

Now that we can refer to this long project URL and username/password with “googlecode”, we use the following command to finally push our local repository onto the remote one:

git push googlecode master

Here “master” is the main branch we want to push. I haven’t really created any new branches yet, so when I work with them more I’ll get more details. For now, I just push the main branch all the time.

And that’s how I got started with Git! It took me a while and a couple of false starts. I’ve tried to explain it right from the beginning for a Windows user with no experience using any version control. Hope you find this useful!