Git, a distributed revision control and source code management system has been making waves for years, and many software houses have been slowly adopting this system as not only their source code repository, but also as a way software development projects are managed.
There is much debate about using either a centralized or distributed revision control system, so I am not going to delve into promoting one system over the other. What I hope to do is shed some light on the rationale and concepts of Git with long-time Team Foundation Server (TFS) users. I would also like to provide a mini tutorial on how to quickly get started on your recently migrated Git projects. The following blog article is my opinion and experience of Git and does not necessarily reflect the position of the company.
Today’s blog article is a summary of what I have learned about Git and the rationale to migrate away from TFS; targeted to long time TFS users.
What is Git?
Git is a distributed revision control and source code management (SCM) system. Note that the keyword here is distributed. The main difference from central revision control systems like TFS, is that there can be no one main repository. Anyone can fork a branch (assuming it’s public) into his/her personal repository and anyone can participate in improving anybody’s branch. Git allows local (on your machine) repositories to be disconnected from the network completely.
If you would like to explore the different repository installations, check out the MSDN blog discussion here and a heated discussion on Stack Overflow here. My two cents: TFS is still viable for projects that require tight integration with Visual Studio and Microsoft products. In these scenarios, TFS functions as more than just a source code repository system.
I find that the following talk by Linus Torvalds explains the true concepts on why Git operates the way it is, and why it is architected so.
Not bothered to watch the whole thing? Summary: Git is architected for an open (as in open source) and distributed (a network of developers) development process.
How Git improves on TFS
I’m approaching Git as a long time TFS user. The following paragraphs assumes that you have sufficient experience in TFS.
Feature work branching
Have you ever found it frustrating to work on multiple features at the same time, and juggle to provide a shelveset that is as minimal as possible, in order to make code reviews easier? Have you ever copied all files in the repository in a different folder just to make sure that the baseline repository is not buggy in the first place? Do you squirm when another team member checks in before you do; which results in you spending a chunk of your time syncing it back in order to check it in?
Git provides an easy way to work on different work items separately by creating branches within your repository. Git doesn’t store data as a series of changesets or deltas, but instead as a series of snapshots. When merging, you do not need to make sure you have all the previous changes in the targeted branch.
All of this can be done without duplicating your project folder and without connecting to the network.
Offline work
Have you ever been forced to wait for slow network connections in order to check out files? What if the network connection goes down? What if you are working away from office and do not have a stable internet connection?
Within a standard workflow, you would always work off a local copy of the repository (known as the local branch). However, apart from that, there is a concept of a remote branch, that represents the state of branches on your remote repositories. Your changes would not be made available to everyone until you ‘push’ your changes back to the remote repository. So, yes. Git still uses a central repository as a communication hub for all developers.
A remote branch represents a snapshot in time of the remote repository on the remote server. With a remote branch snapshot (fetched) locally, you can always fork various copies of that branch to begin different feature work without any connection to the repository server.
Open Collaboration
TFS is tightly integrated with LDAP/Windows Authentication and makes use of this to provide secured access to the source code. However, this hinders wide spread participation from potential coders due to access requirements for checking out files and submitting changes. There is no easy way to fully utilize the capability of the source code repository (code review / change tracking) unless you have certain level of permissions to the project repository.
Git encourages an open source development model, whereby multiple people can fork/duplicate projects easily. If the main branch is only maintained by a single individual, any contributor can propose changes by forking a branch, make the modification and then submitting a ‘pull request’. This essentially means “pulling in a change” or putting the changeset under consideration by the project administrator.
Web Based Code Review
Web Interfaces such as GitHub and Stash have made it much easier to manage projects, pull requests (shelvesets for considerations) and even code reviews. These web interfaces provides a great channel for communication among developers and even observers (this can include managers and product owners) to even participate in the review process; without even using any development tools.
Backup
If the project has many developers, each clone copy of the project on a developer’s machine is effectively a backup. Git intrinsically saves an entire history of snapshots within your local repository. TFS on the other hand saves only the latest synced version of your files.
When not to consider Git
Git it a totally different beast and has different concepts from TFS. It requires some retraining in order to fully utilize the capability of Git.
If you have a small team and do not benefit from any of the above features that I presented above, then there is no significant benefit of migrating away from TFS. In fact, you would lose productive hours and even days learning new syntax and flows, just for the sake of using a new technology.
At the end of the day, it depends on what workflow suits your development projects and if the organization wants centralized control.
Summary
Git is a distributed revision control system that advocates collaboration at a wide scale and supports offline development work. Its killer feature is branching and merging of projects with ease and speed. This style of code management is ideal for parallel development work used by open source projects.
In Part II, I present a set of Git commands analogous to the way you work with TFS projects, in order to get you started right away with Git.