yysun's space

Back to the time of using VSS, check-ins (commits) happened upon when you feel it’s the time to check in. One check in could contain changes for different purposes. Who cares. It is impossible to apply the changes to different branches anywhere.

With git, the commits are visualized like steps of how your software is developed. You would feel shame when seeing yourself mixed up changes together. Actually, if you organize them well, the commits are not only showing good history, but also they can be applied to other branches, called cherry picking. It really let you start thinking to make meaningful commits. And not to mix several changes into one big commit.

The commit message conventions have changed because of the meaningful commit idea. In VSS before, we mostly used the past tense, like “fixed bug 123”, “added new stored procedure”, and etc. It mean I finally have done something. Now in git, the present tense makes more sense. “Fix bug 123” means that if you pick this commit into your branch, it will fix the bug. “Add new stored procedure” means that the commit will you give a new stored procedure. This new style is helpful for cherry-picking. Now the history does not like feature announcements, but has many smaller atomic, maybe reusable steps.

Since we started to be careful on committing, very naturally we want to be able to fix our last commit by adding more changes to it, or even just add some comments. Git commit –amend let us achieve it easily.  In Mercurial, that’s not allowed. because in Mercurial, change sets are immutable. It is difficult to make correct commits just one time deal.

My branching and merging presentation to developers went really well. I demonstrated the 3-way merging (using KDiffs), then branching and merging in TFS and in Git.

Here is the scenario. There are conflicts in V1.1 and V 2.0.

Using 3-way merging, conflicts are automatically resolvable. That is something cannot be done using the 2-way merging.

I mentioned my one of my two big disappointments in TFS merging. By default TFS dose 2-way merging, not 3-way. The above scenario requires manual resolutions to the conflicts.

Update: after the presentation, I was able to set KDiff3 as the diff and merge tool in team explorer, followed this tips from this blog post.  It then can automatically resolve the above conflicts. But I am still not sure if TFS will be as good as Git in more complicated scenarios.

Next, I compared TFS and Git on branching. TFS creates a copy folder for the new branch. For big projects, it could be slow.

I don’t really care about branching, but merging must be good.  Here is my second disappointment about TFS. By default TFS can only merge branches that are direct parent or child. I cannot merge V 1.1 to V 3.0.

We still like the project management/work item tracking and build features of TFS.

How to use Git with TFS? My suggestion during the presentation was to check out TFS projects as master and use Git locally. Like it is described here. The source control binding information in solution and projects are headache to deal with though.

I tried git-svn and TFS SVN Bridge against codeplex. It works well. I am waiting svnBridge’s new lease that supports TFS 2010.