Blog

If you've been reading my blog, it should be clear by now that I'm a bit of a fan of the Git version control system.

I've been hosting some projects on Unfuddle for a while now, but have not been very happy with fiddling with SSH keys and setting up the central repositories through the Git Extensions for Windows. It works, but that's all I can say.

Another issue I was not looking forward to tackling was setting up TeamCity to pull from Unfuddle. I haven't tried, and for all I know it might work great, but if there's a perfectly good shortcut that I can take, I'll take it!

A few days ago I saw some tweets from people mentioning Git and DropBox as a combo. Unfortunately, I can't find the messages any more as Twitter's retention policy seems to be very aggressive. So I decided to try doing it myself.

The advantages of having a Git repository in DropBox are that:

• it does not rely on a service that (for all I know) might go out of business one day;
• it prevents me from having to create SSH keys as credentials;
• it makes it easier to point TeamCity to a central git repository (which is in fact on the local disk);
• the central repository is always synced to all of my dev machines and to the DropBox server, so there is multiple backups in case of catastrophic failure;
• you will always have the ability to push changes to a central repository, even if you have no (or intermittent) internet connectivity;
• if you have to work without internet connectivity, but with network connectivity, you could just set-up a network share and push and pull to each of the repositories that way.

I'm wildly enthusiastic about the distributed nature of the Git version control system, it really does allow me to work from anywhere and in any way that I want.

Setting up Git with DropBox on Windows

I am assuming that you have DropBox installed and that you are using the Git Extensions that I've mentioned in earlier blog posts on Git.

I've created a folder somewhere in my DropBox folders that will hold my Git repositories. In there, I've created a folder called "Example.git".

Next, I created a new Git repository using the Git Extensions. When you start Git Extensions, choose "Initialize new repository" from the "Commands" menu.

I created a "Central repository, no working dir" in the "Example.git" folder.

Then, in the folder that holds my Example project, I created a personal repository, as I would do normally when putting you project under version control (again through "Commands", "Initialize new repository").

This will open up the repository in Git Extensions. The first thing I like to do is hit the "Edit .gitignore" button, add the default ignores and commit that as the initial commit.

With that inital commit out of the way, I will add a remote from the "Remotes" menu.

I've name the new remote "DropBoxExample" and instead of entering a URL, I point to the "Examples.git" folder that I created earlier.

After clicking the "Save" button, Git Extensions will ask if I want to automatically configure the default push and pull behavior, I've skipped this step because the folder on the disk is not actually a server that understands commands. Then I closed the "Remote repositories" window and start pushing the master branch to the remote.

And got a confirmation message, it worked!

Now I am able to actually set the pull defaults, so I go back to managing the remote, go to the "Default pull behavior" tab to choose the defaults from the dropdown lists and clicked "Save".

All done!

I went to my other machine and created the same "D:\Dev\Example" folder.

I opened up Git extensions and initalized the folder as a personal repository. Then I was able to add the remote repository in exactly the same way, instead of entering a URL, I pointed to the "Example.git" folder in DropBox, saved the remote and pulled from it.

To my delight, I saw the .gitignore file appear immediately and noticed that I had received the commit history from the other machine. Success!

Of course I then proceeded to add a Visual Studio project, pushed it to the central repository, pulled it in on the other machine, and again, everything appeared as I hoped it would. Success!

So now that you've started using Git, you might want to share your repository with your team using a central repository. I'll show an example of how to do that by using a free account at Unfuddle.com.

Sign up for Unfuddle and log in to your account (through your_account_name.unfuddle.com). Go to "Repositories" and create a new Git repository.

Now you have to create an authorization key, to be able to log in to the Git repository remotely.

Go back to Visual Studio and click Git's "Browse repository" (the folder icon) button again. Then in the menu go to "Remotes" > "PuTTY" > "Generate or import key".

Make sure the settings for generating the key are correct, the key needs to be 2048 bits.

After you've generated the key, change the key comment to your e-mail address, and enter a passphrase for the key. Now, make sure you copy the key from this window! Saving the public key generates a slightly different format, but Unfuddle really needs the format as it is in this window.

Save the public and private key somewhere anyway, you'll especially be needing the private key later.

In Unfuddle go to "People" > and edit the Account admin. In the bottom left you can enter a "New public key...".

When that key is accepted, go back to the "Repositories" tab and find the repository server, under your repository title (something like git@your_account.unfuddle.com:your_account/abr.git), copy this address.

Now you can set up the remote server in Visual Studio. In the menu bar, click "Git" > "Manage remotes". Give your remote server a name (no spaces) and paste the address you just copied.

Browse the private key that you stored earlier and choose hit "Load SSH key". Enter the password for that key and then you can save the connection. For some reason the "test connection" button fails for me ("ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment."), it still works though.

So now you're ready to push whatever is committed in your current branch to the remote server, use the blue up arrow ("Push changes to remote repository") to do so. You could also then push all branches and tags, or do a pull first to resolve any merge conflicts if you want.

In the next part of this series, I'll give a quick rundown of branching and merging.

So you're ready to start using Git? Here's how to start:

First of all, go and download and install the Git extensions for Windows. The featured (full) release is recommended.

In Visual Studio, you'll now see a few new buttons (in Windows Explorer, there's also some new context items that will show up when you right-click a folder).

As you can see it's a tiny toolbar, click the last icon (settings), you have to set a name and e-mail address, they will be attached to any commit you do.

I've noticed that in order for the toolbar buttons to work, I have to open a file in the solution. So just open one of the files and make sure the cursor is in the file somewhere.

Hit "Ok" and click on the folder icon ("Browse repository"). You'll be presented with a screen with three options, one of which is "Initialize repository".

Initialize the repository in the root directory of your solution, this is typically where your .sln file is. The content in this folder and everything in the subfolders will be under source control. This is also your personal repository, there is not even a central repository yet.

The repository is simply one .git folder in the solution folder.

Almost done!

You're ready to commit your project to the repository. First, make sure you ignore the appropriate files, hit the "edit .gitignore" button and add the default ignores. For me personally, this is all that I need, you might want to tweak it.

Ready. Now you can do your first commit! You can skip the "Add files" button, this will just stage all the files for a commit, you can also do this in the commit screen.

Select all of the files and click "Stage selected files", type a commit message and click "Commit".

This creates the first branche, called master. You're good to go code and make changes. When you're ready to commit again, just use the tiny toolbar button instead of the repository browser.

In the next part of this series, I'll show how to commit the changes to a remote repository using Unfuddle.com.

Version control systems are evil. They hate me and are out to get me. I can't count the number of ways that I've been bitten by SourceSafe (safe.. ha! get it?), CVS, SVN and TFS.

Enter Git, my saviour. For now. I have literally worked with Git for three days, so I know very little and I can't claim that it will be any better than the rest of them, but it sure seems like a great system and I've seen very good reviews online.

Advantages

Working with Git, as opposed to other source control systems has some key advantages.

Git is great for experimental projects, where you want to give your developers the power to experiment wildly without any of their experiments getting into the source control system if they don't work out. Making a new branch in Git is easy, merging the branch back is quick and simple. Git just gets out of your way and does the hard work for you.
Of course you could still have merge conflicts sometimes, and they need to be resolved by hand, but at least you can trust the rest of the merge to go well (unlike the horrors I've seen in CVS and SVN).

One of the things that I really like is that Git only creates one folder in your source code file structure and not one folder for each directory (like CVS/SVN). Git also does not require all your files to be read-only, like in TFS. And finally, you can just move/delete files without all kinds of errors popping up, Git just detects the move or deletion.

I have a local repository of all of the files and history my project, I can commit frequently to the local repository and when I am satisfied about my work, I could send it to a remote, central repository. Having a distributed repository also means that I am never tied to a network/internet connection to use source control.
Also, when the central repository is down, I could just find a team member that has a recent copy and pull down their repository while I wait for the central server to be fixed.

Using the Git Extensions for Windows gave me another nice little productivity nugget: a sensible and (as far as I can tell) complete list of files that need to be ignored while committing changes. Everything from "Thumbs.db" to the Resharper folders is in there, cool.

As I understand it, Git also works great with large sets of files and large teams. The Linux kernel is under Git source control and that's a lot of files and a lot of collaboration.

There are plenty more features that are cool like cherry-picking commits, the built in CVS proxy server, octopus merging, etcetera. If you want to read more, go and have a look at the Git Wikipedia article. There are some great video's on YouTube as well if you want to understand Git better. Remember that on the Windows side, you don't even need to know the command line syntax.

Disadvantages

I really haven't found any disadvantages yet to using Git. Sure, it's a new system and there's a few things to learn, but that's about it. I've only spent about a day understanding Git and I feel very comfortable already.

Of course, once I start using it more often and in a team scenario, I might run into some difficulties, we'll see.

In the next post, I'll show how easy Git is to set-up and use in Windows with Visual Studio (again, unlike for example SVN).