Tag Archives: git

A simple intro to git on Windows

I’ve heard a fair amout about git in the last year, various people singing its praises for long enough that I figure its worth checking out for use with my projects.

Some history

Git was developed by Linus Tovalds in 2005, as the source control for Linux kernel development. He was inspired by the workflow provided by another proprietry tool called BitKeeper, which up until that point had been free for the Linux developers to use.

Why use it?

Basically my understanding is that the major benefits of git are (by no means an exhaustive list):

  • It is a distributed VCS, so developers can push and pull changes from each other. There is no concept of a central repository, except by convention (i.e. a team decides there is one).
  • It facilitates managing local branches, housing local repositories and working copies, so that developers can perform ‘offline’ commits to their own repositories, and update remote repositories when it is convinient.
  • Merging is done intellegently, by delving into the history of both working copy and merge target, and applying each change to the state the target was in at the time the change was made.
  • It is very quick to branch and switch between branches

Two opportunities arose recently which has given me reason to try it out:

1) A presentation by a collegue on his use of git-svn (albeit on a mac, when most developers are using Windows)

The presentation was more like an info session, not a suggestion that we should all be using it too. It was interesting to see how well it worked for his workflow though, and actually seeing it demonstrated was much more productive than another less experienced co-worker who constantly complains that git is the solution to our process problems.

2) A side project, collaboration with a friend on a project.

Git is being used as the SCM with ssh access to a remote repo, maven builds on a TeamCity build server.

git on Windows

So my home machine at the moment is a Windows box (mostly because of digital audio applications I use), I investigated my options with a Windows git client.

  • git via cygwin
    • The official git implementation for Windows, via cygwin’s command-line interface.
    • Apparently is noticibly slower than native implementations on unix, due to cygwin’s fork implementation
    • Some are concerned about the disk and CPU overhead of running the emulator on their system.
  • mSysGit
    • The official alternative to cygwin, uses its own bash shell and/or git-gui
  • Tortise Git
    • If this is anything like Tortoise SVN, this would be perfect for a development environment. Might be good to take this one back to the folks at work (they’re all used Tortoise SVN)
  • Git#
    • A .NET native implementation for Windows, GUI
  • IDE based – IntelliJ 8 and Eclipse both have support via plugins
    • Probably the easiest since I’m using IntelliJ, but I like having an alternative to opening up an IDE to do some version control maintenance if neccesary.

I prefer a command line, so I’ve stuck with what I know and installed cygwin with the packages git, gitk, vim and openssh which should be enough to get started.

Basic workflow with a remote repository

Basic git workflow

Basic git workflow

A basic workflow using a remote repository as your starting point looks something like this. A remote repository may exist outside your computer, somewhere over the internet perhaps… On your machine however, you have 3 components:

  • Local repository – The clean copy of all files in the project.
  • Index (or staging area) – A holding area for the changes you want to send to your repository.
  • Working copy

Git manages the local repo and index in hidden files in the project directory, so all you see is the files you’re working on – the working copy.


Create your local project by cloning the remote repository (I’m using ssh):

git clone ssh://user@server/path/to/project

This will create the local ‘clean’ repo, index, working copy, and initialise the various git files.

After creating or modifying a file, add it to the staging area so that it is available to commit:

git add filename.ext

A commit will commit from your index to your local repo. A push will then push those changes to the remote repository:

git commit -m 'Some message'
git push

Note: A shortcut is to use the ‘-a’ flag on commit, it will automatically stage and commit all modified files so you can skip the ‘add’ command.

Alternatively, to rollback a change you made (this will revert to last available version from the staging area):

git checkout filename.ext

To update from the remote repository:

git pull

There you have it, seems pretty straight forward to get started. And those with experience with other VCS/SCM software should have no problem adapting.


Check some of these links out for more info: