LexParse

It’s been one year since we decided to switch to Git from Visual Source Safe. We’ve had up to 6 developers using Git with our .NET Visual Studio solution which consists of 31 project and 3000+ source files(C#, F#, ascx, etc…). Git is an amazing piece of software. If you are not using it, stop what you are doing, download it, and start learning it. I’ve used Perforce, MKS, Mercurial, and CVS/SVN, but it would be very sad for me to go back to using something other than Git.

Before I get more into Git, I want to get one thing straight: Source Safe is not source control software. At best, it’s a fat random byte generation layer on top of the file system or network stack. Calling it source control is the “biggest scam perpetrated on the American public since One Hour Martinizing”.

Git does not have the notion of a central repository built into it, it is distributed. You work directly on a repository. Usually this is your own local repository. You commit changes locally. You have all your history and branches locally. Branches can be shared across repositories by pushing and pulling. Git comes with its own network protocol for doing this, but there are other protocols that can be used like SSH. By starting with this distributed architecture, the very notion of having your own repository means you are working in your own seperate branch (a local branch can be tracked to a branch in a remote repository). The result: branching is EASY. It’s built in. It’s part of everything you do.

Just because it’s distrubited doesn’t mean you can’t work with a repository that is considered the “central” or master repo. This is what we do. We all cloned from the master repo. Our master branch is “tracked” to the master branch in the master repo. We work locally, commit, and push our changes to the central repo (you might have to pull first before doing a push if you’ve changed files that someone else has). We create other branches and push them to the master branch so that they are available to other developers when they do a pull. Merging is done on pulls automatically. Everything just works.

I’m not going to give you a course on Git here, there are other good sources for that, but I will give you some starter tips:

• Get the msys Git for windows. Cygwin is evil.
• Get git extensions. It adds git functionality to file explorer and Visual Studio.
• Git, by default, considers all the bytes within all the files in the file system tree starting at the top level repository directory part of the repository. Any bytes in that file tree are fair game. This behavior can be changed. See below.
• Don’t think of the repositories as files and directories. Think a big byte blog. Changes that happen are not happening in files, they are happening somewhere in this big ball of bytes.
• Tags, branches, and commits are all the same thing: references to some point in the repository. Branches have a different work flow.
• For visual studio projects, we use a .gitignore file with these contents:
  *.pdb
  *.dll
  *.exe
  *.suo
  *.scc
  *.vspscc
  *.user
  *.cache
  *.log
  *.rdl.data
  bin/
  obj/
• For merging:
  1. Download p4merge.
  2. Create a batch file called p4diff.bat with the following contents and put it in the c:\windows dir:

  p4merge %2 %5

  3. Add the following to the end of your .gitconfig file under c:\Documents and Settings\Username
  [mergetool "p4merge"]
  cmd = p4merge $BASE $REMOTE $LOCAL
  [merge]
  tool = p4merge
  [diff]
  external = p4diff.bat

  Now, when you call git mergetool p4merge will be used.