How To Create New Branch In Tfs Visual Studio 2017

We've always been able to host our Visual Studio-based solution source code under Git. The problem was, unlike Team Foundation Sever (TFS), Git suffered from a lack of integration into the Visual Studio IDE. Today, that lack of integration is a thing of the past! Recently, Microsoft made Git a first class citizen in TFS. Today, we can choose either TFS or Git for our source code control (SCC) provider on our team projects. To make things work with Git, Visual Studio 2013, as part of its install, also installs Git. Does this mean you have to use TFS or Visual Studio Online to take advantage of Git in Visual Studio? The answer is no. In this article, I'm going to show you how to make Git come alive in Visual Studio - using only what Visual Studio gives you in the box.

What If You Don't Have Git Installed?

In the event you don't have Git installed, navigate to https://git-scm.com/. Just follow the instructions and accept the defaults. Figure 1 illustrates the git-scm download page and a command prompt window. If, at the command prompt, you type git and usage guidance and a command list is echoed back, you are good to go!

Figure 1: The git-scm windows download page and the command prompt to verify the git install

New to Git?

The remainder of this article assumes you have at least a working knowledge of Git. If you don't, that's OK. The good news is that with Visual Studio, you don't have to understand, out of the gate, how Git works, although at some point, you'll want to be acquainted with how Git works and its command line syntax. One of the best resources to learn Git is the free e-book called "Pro Git," by Scott Chacon, illustrated in Figure 2.

Figure 2 : Pro Git by Scott Chacon is a free e-book available on the git-scm.com site.

Git Version Control versus TFS Version Control

The primary difference between Git and TFS Version Control (VC) is their respective type. Where TFS is centralized, Git is distributed. In a distributed VC system, each client has its own local repository that is synced with one or more remote repositories. Each local repository, among other things, is capable of branching, merging, and commits. In a centralized VC system, there's only one repository that's hosted on a server. It's only with that centralized server where branch, merging, and commit activities occur. In a centralized model, developers must have consistent connectivity to the central repository to get the advantages of VC. In a distributed model, developers only need connectivity when they need to sync their changes. Recognizing the value of distributed VC and Git's popularity, Microsoft baked Git into TFS. Now, when you create a TFS or Visual Studio Online Team Project, you pick your version control provider: Git or TFS.

The Git support in Visual Studio is not some customized version of Git. Rather, the support is for Git itself. In addition, there is support for common remote Git hosters like GitHub and BitBucket. If your project happens to be in a directory that has an initialized git repository, the Git features in Visual Studio, as you'll see in a moment, "Light up." Of course, to get the benefit of associating work items with source code commits, you need to use TFS or Visual Studio Online.

Getting Started: Creating a Remote Repository on GitHub

Figures 3 and 4 illustrate the new GitHub repository.

Figure 3 : When you create a repository in GitHub, you can specify a number of options.

Figure 4 : Main GitHub page for the repository

With the GitHub repository created, the next step is to clone the repository to a local Git repository. To do that, you'll use Visual Studio and specifically, the NuGet Package Manager Console.

The Git support in Visual Studio is not some customized version of Git. Rather, the support is for Git itself.

Cloning a GitHub Repository with PowerShell in Visual Studio

PowerShell is a powerful tool; Visual Studio ships with a PowerShell Command Window. You know it as the NuGet Package Manager Console. Figure 5 illustrates that PowerShell has no issues with the Git command and, as you can see, cloning a remote repository is quite simple.

Figure 5 : Executing the Git Clone Command from the NuGet Package Manager PowerShell Console

Figure 6 confirms, via the File Explorer, the cloned repository.

Figure 6 : The cloned repository as shown in the File Explorer. Note that the context menu recognizing the directory has a Git repository.

In the next step, The Visual Studio Team Explorer will be connected to the local repository.

Connecting Visual Studio to Git

Figure 7 illustrates the New Project dialog. Note that the local Git repository is located in the directory.

Figure 7 : The new project will be saved to the new Git repository's home directory.

You aren't quite done. You have to tell Visual Studio to add the current solution to source control. Figure 8 illustrates how to invoke this menu option.

Figure 8 : To add a solution to Git source control, the Add to Source Control menu option has to be selected.

Once the project has been added to source control, the Solution Explorer reflects that status. Figure 9 illustrates the Solution Explorer.

Figure 9 : When the Add to Source Control menu option is selected, Visual Studio detects the existing Git repository.

If you elect to add a project to source code control, you are prompted to choose between TFS and Git. Figure 10 illustrates how this works. The Output Window confirms the creation of a new local Git repository (assuming that is the option you chose). In this sequence, you have to associate your local Git repository to your remote repository. To this, you issue the following command:

          git remote add origin https://github.com/user/repo.git

Figure 10 : Once the Git option is selected, a new Git repository is created. From there, it's easy to specify the remote repository in the Package Manager PowerShell Console.

With the Visual Studio Project under Git Source Control, it's time to turn your attention to the Team Explorer.

Working with Git and the Team Explorer

Figure 11 illustrates several things. First, Visual Studio is not connected to any TFS. Once upon a time, in order to use the Team Explorer, there needed to be an active connection to TFS. This new native support for Git changes all of that. TFS is a great environment, but it's not for everyone. Why should native and integrated support for source code control have a dependency on TFS?

Figure 11 : Once a solution is placed under local Git source code control, the Team Explorer is available to use. You no longer need to be connected to TFS to use the Team Explorer.

From here, if you're familiar with how to use the Team Explorer to commit changes to a source code repository, you already know what to do. Figure 12 illustrates the basic work flow. First, you select the Changes Button in the Team Explorer. Once you provide a commit message, you can commit these changes to your local repository. There are three options:

Commit: Pending changes are sent into the local repository only.
Commit and Push: The same as Commit with the added step of sending the changes to the remote Git repository (hosted in GitHub for this example).
Commit and Sync: The same as Commit and Push with the added step of bringing any changes in the remote Git repository into the local Git repository.

For this example, you'll just Commit and then sync your changes in a separate step.

Figure 12: Committing source code changes in the Team Explorer works just like committing changes to a TFS Source Code Repository.

Figure 13 illustrates the results of the first commit. It really is that easy. Everything that was done with the Team Explorer could have been done with Git commands via the command prompt, Git Bash, or as previously demonstrated, the NuGet Package Manager PowerShell Console.

Figure 13 : Using commit history as an example, inside Visual Studio, you can elect to use the Team Explorer, a command prompt, or some combination when interacting with Git.

It's important to note that while you can accomplish most things with Git in the Team Explorer, there are some functions that require you to use the command line. A good example of this is the git stash command. There is no facility in the Team Explorer to stash current work without committing that work before switching to another branch.

Now that you have committed your changes, the next thing you need to do is push those changes to the remote server. That step is illustrated in Figure 14.

Figure 14: From the Team Explorer, it is very easy to sync the local and remote Git repositories.

That's all there is to syncing with the remote Git epository. The local repository knows about the remote repository because the local repository was created by cloning the remote repository. If, on the other hand, you create the local repository first, you have to invoke the git remote add command.

About Branching and Merging

Branching and merging is very easy to accomplish within the Team Explorer. To demonstrate, let's create a branch called development. Figure 15 illustrates that work flow. Note that the Checkout branch checkbox is checked. When you check out a branch, it makes that branch the currently selected branch. You're always on a branch. When you first create a repository, there's one branch called master. This is the root branch, or what is often referred to as the trunk. The idea is that over time, the trunk will sprout branches like a tree. Eventually, activity in those branches is merged back to the trunk over time. Before you can switch branches, you either have to commit or stash your work. Stashing work places your work in a temporary holding place without the need to commit to the current branch.

Figure 15 : From the Team Explorer, it's very easy to create local branches and publish those branches to the remote repository.

Figure 16 illustrates the new branch in the remote repository hosted in GitHub. Now, that branch is available for other developers to use. When they sync their local repositories, they will be able to work in that branch.

Figure 16 : When a branch is published, it becomes available in the remote repository.

Today, regardless of whether you're using Team Foundation Server or Visual Studio Online, you can leverage Team Explorer for managing and interacting with Git source code control.

Merging is just as easy. The following list enumerates one possible workflow.

Checkout the branch you wish to work in. You can either use the git checkout command or you can select the branch in the Team Explorer.
Make your changes.
Sync your local repository with the remote repository, making sure that your local copy of the master is up to date.
Commit your changes in the branch.
Merge your changes from the branch (source) to the master (target). You can also merge from one branch to another branch. Or, you can merge from master to a branch.
If there are no merge conflicts, sync changes with remote repository.

Figure 17 illustrates where and how to initiate a merge in the Team Explorer. As with everything else, you have the option of initiating these operations via git commands in a command prompt.

Figure 17 : Merging, like branching, can be initiated in the Team Explorer.

Conclusion

As you can see, Git is now a first-class citizen in Visual Studio. You've always been able to have your Visual Studio-based projects controlled in Git. That process wasn't integrated, and you had to rely on an external command prompt or some other Git user interface. Today, regardless of whether you're using Team Foundation Server or Visual Studio Online, you can leverage Team Explorer for managing and interacting with Git source code control. Prior to these latest changes, in order to use the Team Explorer, you had to also connect with and use a TFS Team Project. Today, your remote Git repository can be hosted anywhere. In this article, GitHub was used, but another service, such as BitBucket, could have been used as well.

In spite of all the graphical user interface goodness that Visual Studio gives us, there are times when you need to use a command prompt to interact with Git. You may also be a developer who's more at ease with the command prompt but have missed that integration in Visual Studio. With the NuGet Package Manager PowerShell Console, you have a fully functional Git command window that is fully integrated in Visual Studio.

With Visual Studio, you don't need to worry about having to be a Git command-line ninja. Instead, you can leverage Team Explorer for most of your functions. Over time, in order to get the most out of Git, you'll want to be acquainted with the raw commands. The good news is that you can ease into that knowledge while remaining productive with the Team Explorer.