Git as a branch container and Visual Studio

One of the features, that differentiates Git from other DSCM like Bazaar and non-distributed SCM like Subversion, is that it holds all of your branches within .git repository that’s in your working copy directory.

Some of devs consider it a disadvantage: you get main development line and all of the branches in one working copy; others as an advantage – since you get all the repository in one directory.

Subversion and Git

With Subversion you checkout, hack hack hack and commit. That’s fine. Now you need to create a branch so you can develop a feature without sacrificing changes on trunk. The workflow is pretty straightforward: branch within repo (fast), branch checkout (slow), hack hack hack and commit. But what’s hidden under hack hack hack?

A complete project rebuild at start. Why? Because you’ve just checked out a branch to a separate directory. If you have a smallish VS solution with a couple of projects – it doesn’t matter – but if you have a solution with 100+ projects… time to get a fresh cup of coffee!

Now the same with Git: create a branch (fast), branch checkout (fast), hack hack hack and commit. Simple as that. But since we have all the branches within our repo/working copy and checking out only swaps modified files and these are none on clean branch – what do you need to rebuild? Nothing. No changed files = no rebuild.

Of course one might use “switch” command of svn but it has several disadvantages:

  • It’s slow; svn needs to check all the files on the remote repository since local copy has no information on branches
  • It destroys all working copy modified files (correct me here if I’m wrong)
Bazaar and Git

Even though Bazaar is a DSCM you branch to separate directories. So cost of creating a new branch is as high as with Subversion: after branching you need to rebuild whole project. Moreover I don’t know if Bazaar supports “switch-ing” (as with Subversion) at all.

Of course this is an initial cost and after that if you want to switch within Visual Studio you either open new instance or load new solution.

With Git it’s much more comfortable: just checkout new branch and Visual Studio will detect and reload all open files that are modified. Simple and fast. You don’t even need to remember what files you were working on.

This feature of Git has also other advantages:

  • Backup: you backup one directory and only one directory and it’s whole repo!
  • Merge between branches: no separate directories need to be given/checked, just checkout to destination branch and merge the source branch.
  • Easy on fingers: no cd-ing around if you use console

But all of this is pretty subjective as usual…

About these ads

6 responses to “Git as a branch container and Visual Studio

  1. SVN branching is seriously broken in many ways. In SVN pre-1.5, there is no merge tracking: Makes branching/merging absurdly complex, actually many people are used to thinking that merging is difficult because of SVN.
    Even SVN 1.5 will have an underrated misfeature: When a merge is done, all changes made in the merge are owned by a single user, the person that did the merge. This actually makes svn blame useless if you’re going to do branching.

  2. Yes, you’re wrong about “svn switch” destroying local modifications.

  3. Can you please elaborate on this a bit more?

    The Subversion book states:
    “After “switching” to the branch, your working copy is no different than what you would get from doing a fresh checkout of the directory.”

    To me this means that if you have any modified files – all these modifications will be removed…

  4. One more thing ou forgot to note: SVN and CVS have plugins for VS source control. I haven’t fount ANY that will bring Git or Bazaar to it.

  5. In case anyone was left thinking there is no VS plugin, the image here probably says its best:
    http://fooberry.com/2009/02/17/git-extensions-and-visual-studio/

    Project page:
    http://code.google.com/p/gitextensions/

  6. As Duffy commented you are wrong about ‘svn switch’ although it holds some truth in practice since git is much better at storing temporary work states that you don’t want to commit to the central repository (‘git stash’, ‘git commit’ wo push). With svn i usually use ‘svn diff’ to create a patch which i can apply later. It works pretty well for me, but git handles it better.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s