Git in Team Foundation Server 2013

Now that Team Foundation Server (TFS) 2013 provides the option to use either Team Foundation Version Control (TFVC) or Git for your source control repository, you need to understand the pros and cons of each option. If you decide to use Git, you need a good plan so that your transition is smooth and so that you get the biggest benefit from Git. In this article, I explain the benefits of using Git.

Related: Top 5 Visual Studio 2013 Features for Agile Development & DevOps Collaboration

What Is Git?

Git is a distributed version control system (DVCS) that lets you work disconnected while still having access to your complete source code history. Git includes all the source control features you expect—branches, merges, labels, commits, and more. As a Git user, you commit your changes to a local repository, and you can push your commits to a remote shared repository. Also, just like the commits, all your branches and merges are performed on your local repository.

Benefits of Git

Git has many benefits over other version control systems, especially over centralized version control systems (CVCSs). The obvious benefits are that you can work from anywhere while still being able to access the entire source control history for all your files and that you can switch between all your branches and view their histories.

However, the disconnected nature of Git provides more benefits than just freeing you to work from anywhere. By committing locally, Git helps you change your workflow to store your changes in source control more often than you would if you were committing (checking in) your changes directly to a centralized source control repository such as TFVC.

Like most developers, you've probably run into situations in which you needed to revert your code to where you were minutes or hours ago. With Git, you don't have to worry about integrating your code with the rest of your team every time you commit, so your commits can be used as checkpoints throughout your coding sessions. If you decide to go back to a previous version of your code and continue working from there, you can easily do so using your commit as a checkpoint without affecting anyone else on your team.

Similarly, you can benefit from local branches to either work on side-by-side code streams or on code prototypes without affecting your main code stream. The way Git tracks changes makes merging between branches—even branches that don't have a direct relationship—much simpler than merging is in other systems. To learn more about the way Git works, download Git for Windows and try it yourself with a local repository.

Git with Visual Studio 2013

Starting with Visual Studio 2012 Update 2, and enhanced in Visual Studio 2013, Git is integrated right into your IDE. If you're using Visual Studio 2012.2, you need to install Visual Studio Tools for Git from the Visual Studio Gallery. Visual Studio 2013 has this functionality built in, so you don't need to install any additional tools. This integration means you can work with Git directly from your IDE rather than using the command line or third-party products. Visual Studio's Git integration lets you do such things as create local repositories, commit, create branches, merge between branches, view history, and push and pull from remote repositories. Future Visual Studio updates will enhance this functionality.

Visual Studio's Git integration is built in to Team Explorer. To get started with Git from Visual Studio, you must first set your current source control plug-in to Microsoft Git Provider. Select Tools, Options, Source Control, Plug-in. After you configure your source control plug-in, Team Explorer will look different than it does when you're connected to TFVC (see Figure 1). Note that the Visual Studio tools let you connect to any Git repository.

Figure 1: Team Explorer Configured to Use Microsoft Git Provider

After you configure Visual Studio to use the Git plug-in, you can create a new local repository, as Figure 2 shows; add an existing repository; or clone a remote repository. You typically perform these functions from the command line, but you can now do so directly from Visual Studio.

Figure 2: Creating a Local Repository

Once you create your local repository, you can create new Visual Studio solutions and add them to the repository. The Solution Explorer context menu gives you Git-specific commands to commit, view history, and undo changes. The commit process is similar to what you might be used to with other version control systems. The entire experience is built in to Team Explorer. Your initial commit will include the .gitattributes and .gitignore files, as you can see in Figure 3; Git uses these files to determine how to behave with different file types. These files contain all the necessary information to work with Visual Studio solutions and projects.

Figure 3: Committing from Visual Studio

You can continue working with your new solution, committing often and knowing that your local commits haven't yet been shared with the rest of your team. If your local repository has a remote repository configured, you can push your changes to that repository after each commit. However, a better workflow option is to commit multiple times locally and push your changes only after you're ready to share those changes with the rest of your team. If you want to see a list of all your commits, you can access this information from Team Explorer by navigating to the Branches section. Right-click your branch and select History from the context menu. You'll see the entire history from your branch, which might include your commits and commits from the rest of your team that you pulled in from a remote repository (Figure 4).

Figure 4: Viewing Your Branch History

From the same Branches section, you can create new branches and merge between branches. Git's branching mechanism is very lightweight and easy to use. If you're used to working in centralized repositories, you know that creating a new branch typically involves a lot of planning and coordination with other team members and that branching is typically seen as an advanced version control operation. Git treats branching differently—it sees branches as an integral part of the way it works, so branching operations are quite simple.

Just like other operations, creating a new branch from Visual Studio is done directly from Team Explorer by clicking the New Branch link in the Branches section (see Figure 4). You then enter the branch name and select the parent branch. At this point, you must decide whether you want to check out the new branch, as Figure 5 shows, or stay on the current branch. The term Checkout might be new to you because it typically means something different in a centralized repository. In Git, checking out a branch means that you're switching your development context from one branch to the other, so all the files in your repository will reflect the files in the checked-out branch. Git doesn't keep separate folder structures for each branch; instead, it keeps a single folder that is updated as you check out different branches.

Figure 5: Creating a New Branch

Merging operations are just as simple. They're initiated from the Merge link in the Branches section of Team Explorer, as Figure 6 shows. Git provides you with a lot of options when merging between branches, including the ability to "squash" commits during a merge. Squashing commits means that all your commits come together into a single commit, which is then the only thing that you see in the history on the target branch. By default, every commit in a branch is applied to a target branch during a merge.

Figure 6: Merging Between Branches

After you're ready to integrate your changes with your team, you need to publish to a remote repository. You can perform this operation from Team Explorer. From Visual Studio, you can publish to any standard Git repository, so it doesn't matter whether your remote repository is hosted on GitHub, BitBucket, TFS, Visual Studio Online, Codeplex, or an enterprise Git server. As soon as you establish the initial association between your local repository and a remote repository, you can push and pull changes between them.

Git and TFS 2013

As I mentioned, TFS 2013 gives you the ability to choose between Git and TFVC as your source control system. You select the option you want when you create a new team project. Note that once you decide on an option, you can't change the team project to use the other option in the future. You also can't have a mix of Git and TFVC in the same team project.

Git hosted by TFS isn't Microsoft's take on Git; instead, it's a full-featured version of Git that happens to be hosted within TFS. Of course, internally it's a custom implementation because it uses TFS's SQL infrastructure to store your source code. You can connect to Git hosted in TFS from the client of your choice, such as the command line, the Xcode IDE, Eclipse, Visual Studio, and others. Also, because Git source control is hosted within TFS, you can leverage some great TFS features, such as work item association and build automation. Just like when you're working with TFVC, you can associate your commits to any task, user story, bug, or work item defined in your TFS team project. Build automation works similarly to how it does when you use TFVC, by letting you configure continuous integration, gated, scheduled, and manual builds. You can even pull source code from a remote repository during your build.

Figure 7: Commit History in TFS Web Access

Through TFS Web Access (TWA), you can view your source control tree, history, and branches, as Figure 7 shows. You can also take advantage of the new Lightweight Code Comments feature introduced in TFS 2013. And you can configure team rooms to receive Git push events to notify the rest of the team when changes are pushed to the remote repository. If your team has been looking for a way to take advantage of Git while using all of TFS's enterprise build, security, and collaboration features, Git hosted by TFS is a great way to get started.

Succeeding with Git

The ability to use Git directly from your Visual Studio IDE is a big step toward successful implementation of Git. After you become comfortable with the tools and various Git commands needed for your day-to-day operations, you and your team should assess your workflow to ensure you get the most out of Git. Although you can keep working the same way you would when connecting to a centralized repository—checking out a file, working on it, and checking it back in after you're done with it—to really get the most out of Git, you need to embrace the process of committing often to your local repository and then pushing your changes to your remote repository after you're ready to integrate with the rest of your team. Don't be afraid to create branches, merge between branches, and experiment with other features such as squashing commits during a merge. Git offers some powerful version control operations that can help you and your team build a more productive and efficient software development process.