Reasons to pass on TFS GIT

We were all hyped to hear the announcement that Hosted TFS now supports Git.

Since TFS has been traditionally tuned for Enterprise (large team) usage, client’s are constantly asking me for a verdict on switching their teams over.

The announcement:

http://tfs.visualstudio.com/en-us/learn/code/publish-new-team-project-vs-git

Unfortunately, I have not been able to recommend Microsoft’s version of hosted git, pointing out the following flaws:

The Missing Fork

Something that strikes me as odd is that the TFS team totally missed the ‘Fork’ concept, which is one of the major responsibilities of a hosted Git solution.

In Git, repositories are more than globs of files in a workspace. Each repository has the ability to be ‘Cloned’, in which the full record of commits is migrated into a separate repository. The intention of this operation is that at some future moment, two diverging repositories can be re-joined given at least one single common commit (SHA).

This is a remarkably powerful ability that teams rely on for day-to-day workflows covering areas of code isolation, security and life-cycle management.

The Traditional GitHub User Story

Let’s take a peek at how a standard code-updates works with GitHub for a larger team:

The Ninja Consultant - Git Style

  1. Bob is a Technical Manager and has a massive repository on GitHub that a group of trusted engineers collaborate on
  2. Andrea is a consultant hired with a specialty for a particular feature
  3. Andrea issues a git clone [repo] on Bob’s repository and commits changes to her Clone.
  4. Once her changes are completed, Andrea submits a Pull Request to Bob to notify that her working repository is ready to be merged into the primary repository.
  5. Bob responds to the Pull Request by reviewing the changes, applying what-ever quality gates are necessary and commits a merge of the changes into the companies repository

In this example, notice:

Let’s use these points to create a more realistic use-case (that I have seen so often it is a hard reality with GIT):

The In-Over-My-Head Consultant - Git Style

  1. Bob is a Technical Manager has a massive repository on GitHub that a group of trusted engineers collaborate on
  2. Jeff is a consultant hired with a specialty for a particular feature, but is super uncomfortable with the solution & Git
  3. Jeff issues a git clone [repo], then totally destroys the master branch by issuing git rebase -i 30 times, trying to climb out of a single bad decision. Jeff then does a git push origin master -f (forcing his changes onto his GitHub fork’d repo).
  4. Jeff then issues a Pull Request to Bob and takes a nap.
  5. Bob responds to the Pull Request by reviewing the changes, issuing a face-palm for hiring Jeff and denies the merge.

In this example, notice:

The TFS GIT User Story

Now, let’s compare that to what TFS GIT allows with branching (without the ability to fork):

The Ninja Consultant - TFS Git Style

  1. Bob is a Technical Manager that has a massive repository in TFS that a group of trusted engineers collaborate on using TFS Project security
  2. Andrea copies down the repository by issuing a git clone [repo]. She then creates a feature branch and commits her changes.
  3. When Andrea is finished working, she issues a git push origin [branch] to promote the branch up to the hosted TFS team repository
  4. Bob gets a Check-in notification, pulls the branch to his local repo instance, applies quality gates and then merges the changes into the master branch

In this example, notice:

Although this process seems harmless from the standard TFS perspective, it begins to severely break down in the more realistic use-case with Git.

The In-Over-My-Head Consultant - TFS Git Style

  1. Bob is a Technical Manager that has a massive repository in TFS that a group of trusted engineers collaborate on using TFS Project security
  2. Jeff is a consultant hired with a specialty for a particular feature, but is super uncomfortable with the solution & Git
  3. Jeff issues a git clone [repo], then totally destroys the master branch by issuing git rebase -i 30 times, trying to climb out of a single bad decision. In this process of destruction, he re-writes 2 years of commit history, resets the code back to the stone-age and creates a web of reflog breadcrumbs.
  4. Bob gets a Check-in notification, pulls the branch to his local repo instance, and calmly accepts that the entire repo is jacked.

At this point, Bob starts getting phone calls from the Engineers and QA teams while he setups up his sleeping bag for a solid 20 hours of recovery.
The team is dead-in-water unless someone happens to have a ‘tip’ version of the repo they can force up

I think the problem here is obvious…

At the End of the Day

Without a solid forking strategy, every team member has the ability to take down the integrity of the repository.

The scariest part is that I have seen this happen many times simply because team members are interacting with their local repository without full knowledge of what effect commands have.

Until TFS GIT offers security blocks around the --force or creates an elegant way to allow fork’s, every team is vulnerable to this accidental attack.

Because TFS GIT decided to not support Forks & the Pull Request, all team members may only commit via the Branching Strategy.

This is a very dangerous approach in that it is relatively impossible to avoid someone

Why I am Steering Clear for Now

Without the ability to trust strangers on repositories and especially without a purposful eco-system for socializing on code, how is a closed-box Git solution any differnt than TFS itself?

Remember, strangers in the source world could range from a 10 years old genius contributing after school to that random voice on your weekly stand-up calls (in an organization to large to send out meeting requests with an attendees listing).

Without the abilty to cleanly manage people, of all types, without effort, a particular GIT implementation isn’t an improvement over TFS or SVN at all.