Just Talking

Introduction

I recently found the time to dedicate to learning a distributed version control system. I had the choice between Mercurial and Git. Both are great systems but what it came down to ultimately was the fact that I already had TortoiseGit on my machine. Yes you read that right, it came down to the fact that I didn’t want another source control provider taking up space in my context menu; frankly my context menu is getting a little ridiculous. I know it isn’t exactly a scientific method of picking between the two, but honestly, I see very little that is different between the two (for a learner).

Initial Reaction

When I first read the description of Git, I thought “who would be stupid enough to have source control on their own machine?” The second thought to go through my SVN-centric brain “I like SVN, so why should I change to Git?” The first question came out of ignorance to the ideas behind a distributed source control system, the second is a completely valid rebuttal.

I will attempt to address the first question. Yes your source control is on your machine but think of it as your own personal local copy of the “Truth.” You edit your version of the “Truth” until you feel comfortable with your additions and changes. The next step is to push your changes to a central version, possibly on GitHub or Unfuddle. That last step is important, because your source is no longer local. Your code now exists somewhere that is hopefully safe, secure, and accessible to you and your team of developers. What is powerful about Git is the fact that most of the expensive actions performed locally: commits, merges, additions, and deletions. This makes Git crazy fast, CRAAAAZZZY FAST! The two most expensive actions are pull and push, but even these can be quick if your central source control repository is on the local network. After a couple hours playing with Git, my ignorance about the ideas behind this system were overcome by an understanding and comfort.

The second question is valid. If you like SVN, why should you switch? Well nobody is forcing you to switch, and people won’t call you a loser if you decide to stick with SVN. I still have a warm place in my heart for SVN, it was the Han Solo of my escape from the Death Star known as VSS (Visual Source Safe). That being said, Git is a lot easier when it comes to branching and merging. In SVN branching occurs remotely on the SVN repository, which can be slow. In Git, branching happens locally and is even encouraged by most resources that I read. The one thing developers might gripe about Git is the fact that there really isn’t much Visual Studio integration. SVN has a ton of integration tools inside Visual Studio. What I would say about this though, is that the projects I work on have more than enough files outside of my VS Solution to negate the good aspects of integration tools. File types like third party assemblies, documentation, build scripts, and other files all exist outside the scope of my solutions. Now to add them to your SVN repository you are forced to use TortoiseSVN, a tool that exists outside Visual Studio.

I may or may not have convinced you to try Git, but I really feel you should. More and more compelling projects are being hosted on GitHub. How will you get involved and help these projects grow with a knowledge of Git? Also, Codeplex now offers Mercurial support, so don’t be suprised when your favorite projects on Codeplex start moving to a distrubuted SCM.

Basic Workflow

To get started with Git download MsysGit. This will setup an environment ready for Git on your windows machine.

I also recommend TekPub, they have a great series about mastering Git.

To learn about a system you have to use it, and that is what I did with Git. I wouldn’t call myself an expert but I do feel comfortable enough with it now to jump into a Git project. The basic Git workflow is as follows (type: “git help” in a command window):

1. init or clone: if you are starting a repository use init, if you are getting use clone.
2. branch: create a new branch to start working in or just work in the master branch.
3. add: add any or all files involved in your project.
4. commit: commit staged files to your local source repository.
5. pull: get any changes that have occurred at the central repository.
6. merge or rebase: make sure all your changes and branches are reflected in the master if need be.
7. patch or push: some repositories online are private so you can produce a patch to send to the owners, if you own the repository the push away.
8. Rinse and Repeat until content.

These are the commands you’ll need to know to just get by, but there are many more to become a master. I modified my environment to work with WinMerge for both merging and diffing. Below are the instructions to get that working.

• You will need to modify your git environment. This is done through modifying the .gitconfig file found in your user folder (C:\Users\<yourname>\.gitconfig).

*Note, when you install WinMerge be sure to check the box that installs WinMerge into your system path.

    external = “c:/users/khalid abuhakmeh/difftool.sh”
[merge]
    tool = winmerge
[mergetool "winmerge"]
   cmd = ‘WinMergeU.exe’ \”$MERGED\”
   trustExitCode = false
   keepBackup = false

• Create a bash script to execute against WinMerge. Create a file called difftool.sh and save it in the same directory. Below are the contents of my file.

#!/bin/sh
echo Launching WinMergeU.exe: $1 $2
"C:/Program Files (x86)/WinMerge/WinMergeU.exe" -e -ub "$1" "$2" | cat
#!/bin/shecho Launching WinMergeU.exe: $1 $2"C:/Program Files (x86)/WinMerge/WinMergeU.exe" -e -ub "$1" "$2" | cat

Now when you execute the commands "git diff @{1}" (compares against previous version)  or "git merge" you will get to use WinMerge to perform those actions. Pretty cool.

Conclusion

So there you have it, my initial interactions with Git and what I have learned so far. There are more things to learn, but I am definitely a convert to Git. Can you Dig Git?