Git for Visual Studio Developers

Git vs Centralized Version Control
This module covers the main differences between Git and centralized version control system. If this is your first experience with a DVCS, and you're coming from a centralized version control system, you may be first tempted to map out each function from your previous version control system, and try to keep the same workflow. And, although you will be able to make it work, I believe that you may very quickly find some problems with your approach. Before we get into working from Visual Studio, I will show you what you need to install locally to be able to have a local Git repository. You should understand how a DVCS works. Specifically, how Git works, and how it expects you to work. Only then you will be able to get the most out of it, and you won't run into major issues using it. We will then go over the concepts of branching and merging, which are key to be able to get the most out of Git. Once you have a good understanding of how Git works, I will cover the workflow that you should follow when working with Git, including how you should synchronize your local repository to your centralized repository. This will prepare you to start working with Git from Visual Studio.

Working With Visual Studio
This module shows you how to work with Git from Visual Studio. Now that you have Git configured locally, and you understand how to use local repositories, it's time to start using Visual Studio to connect to Git and manage your projects. Although you could manage your interaction with Git purely from command line, the ideal situation would be to be able to stay inside Visual Studio and take care of the majority of commands from your IDE. Throughout this module we will go over what you need to be able to work with Git from Visual Studio 2010 and Visual Studio 2012. I will show you the components that you'll need to install, and the process that you should follow. We will then connect to a remote repository using GitHub, and we'll synchronize your Visual Studio projects to it. While at it, we will take a look at some of the features that you, and your team can take advantage of when working with GitHub. Finally, if you're not able to work from a central Git repository, but you still want to be able to work with Git locally, I will show you a way to have a hybrid solution.

TFS 2013
This module covers Git as part of TFS 2013 and TFS Service. Starting with TFS 2013, Microsoft includes Git integrated with TFS. We will go over what it means to you and your team, how to configure, and use it. I will show you the built-in features of Visual Studio 2013, followed by looking at how standard TFS features, such as Work items, and build automation integrate with Git Source Control. Finally, I will show you how you and your team can view and access Git functionality from TFS 2013's web interface.

Pull Requests
This module covers Pull Requests in Git. I will cover the basics of a pull request in Git and take you through the workflow that you will experience while you go through the pull request process. Both Visual Studio Online and TFS 2013 update 4 support pull requests. So we will go through different scenarios and show you the type of notifications that are available to you.

CodeLens
This module covers CodeLens in Visual Studio 2013. Visual Studio 2013 Ultimate, along with TFS 2013 introduced a new feature of CodeLens. This feature, which is sometimes referred to as heads-up indicator, allows you to get information about references, code changes, related work items such as tasks or bugs, and unit tests without leaving the code window that you are currently on. A lot of the indicators found in CodeLens worked whether you used Team Foundation Version Control or Git, but all the code history related indicators only work for Team Foundation Version Control. Starting with Visual Studio 2013 update 3, this limitation is gone and now you are able to take advantage of this feature, even if you're using Git for version control. One of the most useful things about CodeLens is that they are applied at different levels such as method, property or class. So if I look at a method, I can see how many times that method has changed regardless of what has happened to other methods in that class. The same goes for who made the change, related work items, and other indicators. This is huge since I can easily see if I'm in a method that has gone through a lot of changes, or whether there are any related bugs or test cases without having to dig through history or other files in my project.