Great content delivered right to your mailbox

Thank you! Check your inbox for our monthly recap!

This blog is part of a series.

← Read Part 1: A New Dev Series: How We Moved from MS Team Foundation Server to git


Paradigm Shift

Owning git is an achievement.  The key concepts we were used to, such as using a centralized system to share code, are no longer relevant. There are two new key concepts to absorb. Hasty learners who do not take the time to assimilate them will be left behind. Introducing git is not the purpose of this post. Rather, we will map git concepts to TFS concepts.


Everything Is Local

This means all the history of a code base resides in every local repository of every machine the remote repository  has been cloned on. Being a distributed system, git enforces the local history of code base being clean prior to publishing anything remotely. Therefore a git server is just a remote repository with access control and collaboration features. The analogy I use for this is hockey. When you play on home ice, the other team plays away but you play local . Inversely, when you play away, the other team plays on home ice. Once this nuance is understood, you can then more easily understand the notion of having multiple remotes configured in your local repository.

The notion of a clean local repository often introduces the state in which a repository is both ahead and late (when looking at the repository history). This confuses new git adopters. It is important they overcome their confusion to move ahead using git. This only means someone pushed a commit on the remote while you committed a code change (locally). Therefore, you need to pull the change in order to update your local history, and maybe address merge conflicts. Then you can push the result on the remote.

Migration note: TFS acknowledge the fact that the server holds the right code base history. In Sherweb’s dev department, we do the same thing. Our TFS git server is the remote  repository that our continuous integration pipelining system is pulling from.


A Branch Is a Pointer (and Resolve Your Conflicts Locally)

In my humble opinion, branching IS git’s killer feature. It is SO easy to branch with git. As a matter of fact, it is so easy to create branches that a repository may very soon be clogged with branches. Therefore, discipline is key here. In git, a branch is merely a pointer to a commit in the repository’s history. The branch history is only going from the tip of the branch (i.e., where the pointer points to) and moving back in history from this commit to its parent, and so on all the way up to the initial commit. Deleting a branch means removing the pointer, but the history remains intact, so anyone cloning or updating the repository will see where branching and merging occurred. This is quite a revolution for TFS users who are accustomed to see branches as code base copies. We all know how tough this can be.

Migration note:  The team needs to decide which branching strategy it will adopt. Do not enter analysis paralysis here. Choose one, try it and then decide if this is the strategy of choice for your team. If not, try another one. If it is, feel lucky and keep it.

Tune in next week for Part 3!


→ Read Part 3: How We Moved from TFS to git: Owning git (cont’d)

Written by Guy Lépine Employee @ Sherweb

Guy Lépine has a degree in Computer Engineering from the Royal Military College of Canada in Kingston, Ont. He has worked as a computer engineer in the private sector and has also held jobs as a software developer in various application domains. Guy has a diploma in Project Management from the Université de Québec à Montréal and in Electrical Engineering Specializing in Computer Security from the Université de Sherbrooke. Guy has participated in several software development projects using the Agile methodology.