I still plan on writing some posts about how we migrated from TFVC (TFS) to Git. For now, I want to share a few stories of things that happened over the first couple of days that we were officially on Git, and express why I’ve wanted to do this for so long.

Collaboration⌗

Michael and I have been pairing through a story. We’re also realizing that we think a lot alike, and I end up saying things that he’s already doing. We got to that point where there were some rote, trivial things to finish up, and there was a bit of a cut line where it could be done in parallel.

So we did it in parallel.

He pushed the branch, I went back to my desk, and we each committed separately. Then we pushed and merged together on the branch. And it was good. And it was easy. And I honestly think it would have taken us two or three times longer if we were still on TFVC.

Resolving Blockers Amidst Feature Work⌗

During the same day, we were notified of an issue that was blocking test. It’s an issue we knew about, but were planning to do in the next day or two because we didn’t realize anyone was using it yet. As Michael and I discussed it, Will came over; he had been discussing the same with Matt.

Divide and conquer, we sure did!! We pushed a branch. Michael finished up the raw fix that was already in progress, I updated some of our end to end tests to account for it, and Will updated a client library that consumes the API in question. We all pushed that up on a branch. And it was good. And it was easy. And it was mind-blowingly fast.

But wait, there’s more! That feature work…we were still evolving that past what we had done earlier in the day. We were in the middle of that when we became aware of the blocker. We were able to effortlessly switch back to master, make a branch for the fix, and when we were done roll right back into the feature work. No shelvesets or conflicts. No multiple workspaces. No muss, no fuss, just sheer productivity and ass kicking.

Revisionist History⌗

So, carrying on from the above, that bug fix work saw some feedback in code review. Little stuff like missing header comments or using statement arrangement. Or a csproj file not getting committed because Visual Studio doesn’t always save those sigh.

What could have easily been three commits was seven. So we just, you know, made it three instead of seven by doing an interactive rebase to reorder and squash the “Oops” commits into the author’s real commit. Since we were on a branch and communicating with each other, the three of us were ok with doing this even though commits had been pushed previously. Then we rebased and merged that result back onto master, and it looked like we were amazing devs that never forget header comments, using statement arrangements, or to save our csproj.

I’m joking about the benefit of looking perfect. The real benefit here is that it keeps our history looking cleaner, and in the case of the csproj change, ensures each commit is actually buildable.

Time Travel⌗

As all this is going on, we have a situation where we want to deploy to a new environment. We want to include everything that was done at the end of the last sprint (about ten days ago), plus only a subset of what we’ve done since then. We aren’t all fancy schmancy with feature toggles right now, so we actually need some of the source changes and not others. I cannot even imagine doing this on a centralized version control. With Git, we’re just going to

git checkout temp

And then either

git reset --hard <sha from end of last sprint>
git cherry-pick <sha we want>

repeating the cherry-pick for each one we want

Or

git rebase -i <sha from end of last sprint>

only picking the ones we want to keep.

Either way, it’s ridiculously easy. Then we build and deploy from that branch, and master keeps rolling on into the future. Git is the future. Get on it.

Git Fever. It’s Catching!⌗

I was really excited when Rob came over and asked why one of our others projects couldn’t be moved. My response? I’ll have it moved in the next hour or two. And then I did it! This is how much I love Git, and it appears I’m not alone. Now that we’re there, people want more of it.

Optimize for happiness⌗

I’ve been on teams moving to Git before. In the past, even the staunchest opponents have become avid evangelists after a few weeks. I think this is because Git doesn’t just change your toolchain, but it changes your entire workflow for the better. It allows you to do incredibly powerful, useful things and to correct mistakes when they are made. It is built for speed and collaboration.

To put it simply⌗