time I do some kind of talk somewhere, people ask me for advice on how to
convince their management that they should drop Microsoft Team Foundation
Server's source control system and move over to Git.
In this post, I'll be talking about the source control system only. Both Visual
Studio Online (Microsoft's TFS-in-the-cloud), GitHub and BitBucket support this heavily. We use GitHub
ourselves, but I've noticed that Microsoft made some considerable improvements
since we moved away from TFS.
January 2014, after three years with TFS, we finally moved to Git. With 1.5
years of experience, I think we're entitled to having an opinion about how they
compare. To help me compile this post, I asked my colleagues about things they
can do now they couldn't do when we were still using TFS's centralized source
control system. One word of disclaimer though.
You can create and merge
branches in seconds rather than minutes (or hours if your project is
anything but trivial). Switching between branches happens in milliseconds
rather than the typical 15-30 minutes in our projects. This completely
changes the way you work. It allows a level of isolation that is
inpossible to achieve with a centralized source control system.
Pull Requests (PR), a feature supported by
all online Git platforms is a crucial tool for teams to break down complex
software systems in components owned by teams without blocking anybody. It
allows developers to make a kind of copy of projects they don't own, create
branches, work on improvements and new features, and then send a request
to the owning team to pull in their changes. Pull Requests are the single best way
to scale a software development organization into multiple autonomous teams.
How often did you encounter
useless comments like "Oops, I broke the build" or "Some
review rework". You can clean up the history of a feature branch
before you merge it to its final location by using an interactive
rebase to amend
existing commits (the equivalent of a TFS changeset), squashs a couple of
commits together, or to fix up those commit comments.
Developers can work in
parallel on the same branch by merging with other team members, either
from the central repository or on forks owned by individual team members. If they want,
they can use PRs to control what gets in the shared branch.
So you've worked on that
feature for a week or so, but in the mean time, the main development
branch has been changed considerably. Wouldn't it be cool if you could
apply your changes on that newer branch as if you started from that
version in the first place? Well, that's what a Git rebase can do for you.
It keeps the history clean and avoids all those unreadable merges.
Compared to our time with
TFS, we have much less merge conflicts now are on Git. The main reason is
that Git does a three-way merge because it knows exactly
where two branches started to diverge. TFS typically does a pretty dumb
text-based merge. You also have a lot of control how merging should be
handled per file type in that particular project.
You never have to check out
anything explicitly. Just edit it the file in whatever tool you prefer and
Git will pick that up. The project's .gitignore file ensure it will only
monitor specific files. If the net result of your changes is that you
didn't make changes at all, Git will not see that file as changed anymore.
Say goodbye to all those TFS changesets with unmodified files. We did try
TFS's Local Workspaces feature, but that collapsed with large
Everything you can do online
you can do off-line. Last year, I was traveling through Switserland for a
couple of days. The simple fact you can branch, merge and rebase, all from
your local laptop is something you really start to value if you can do
that without an internet connection. This has become instrumental when the
internet connection of my client's project went down. You can even merge
with another colleague's repository over a local network share or USB
Since Git treats branches as
a pointer at a linked list of commits, the entire source code, including
all branches and tags can be downloaded in minutes, if not seconds.
And finally, even Microsoft
made the jump. Git is now the primary source control system for the
on-premise version of TFS as well as Visual Studio Online's. And Microsoft
is maintaining the entire .NET framework on Github.
If you still can't
convince your boss with these arguments, tell your boss how much more
productive you can be with Git. Or you can reverse that argument by telling him
or her how much money he's throwing away every day by sticking with a
centralized source control system.
So what do you
think? Are you moving over soon? Did I miss any good arguments I should
include? Did I exaggerate with any of this? Let me know by commenting below or
tweeting me at @ddoomen.