Tony Patton explains why he thinks the support for Git that Microsoft added in Visual Studio and Team Foundation Server is off to a good start.
I was introduced to source control many years ago with Visual SourceSafe, and I suffered with it for years before finding better alternatives. Since then, projects have evolved from isolated projects within a company to distributed efforts with developers often spread across the world. The plethora of open source projects are prime examples, with a great many of them using a source control system built for them: Git.
The same man who gave us Linux developed Git to handle the ever-changing Linux code base, and now Git is available to developers using Visual Studio. Please, hold your applause until the end.
Spread it out
If you have never used Git, take it for a test drive to get a feel for its power and simplicity. It took me a while to get it (yes, pun intended), but then I was hooked. One simple download, and you are up and running. You can utilize the not-as-hard-as-you-think command-line or opt for one of the many gui clients available.
The key to Git is its distributed nature, whereas the source control systems used most often by the Windows community -- Team Foundation Server (TFS) and Visual SourceSafe -- are centralized, so all changes are managed in a central repository. Git allows developers to control their version of the code, make repeated changes, and then merge into another developer's code or a central code repository.
Visual Studio 2012 + Git
I was initially cautious about Microsoft embracing Git, because I feared the company would try to "fix" or put its own spin on Git and call it something like Mit, but thankfully it is standard Git. While all future Visual Studio versions will include native Git support, it can be added to Visual Studio 2012 via the Visual Studio Tools for Git extension. Simply download and install the extension, and you are in business.
The projects created and managed by Visual Studio 2012 and Git can be used by other Git clients or the command-line. Once installed, you will notice new options within the Visual Studio 2012 environment. First, the Team Explorer tab now provides Git options (Figure A), allowing you to choose a TFS or Git repository with the ability to create new Git projects as well.
Team Explorer allows you to browse Git repositories.
One of the first things you will do is set your username and email address so you can use Git's features; you do this via the Settings tool icon in Team Explorer (Figure B). Figure C shows the options set, along with repository options for adding an ignore file (files to be excluded from source control) and an attributes file. When editing code, context menus provide access to Git commands for committing/undoing changes, viewing history and compare (Figure D). Once files are added to source control, the changes will appear in the Team Explorer window with sections for Excluded files and more (Figure E). The Branch menu (Figure E) lets you create and manage branches within the repository.
Configure Git settings via Team Explorer
Managing Git settings in Visual Studio
Context menus provide access to Git commands.
Working with Git files in Visual Studio.
What about TFS?
Microsoft added basic Git support to TFS as well. You can use Git to provide source control of a code base, and any Git client along with the Visual Studio 2012 Git plug-in can be used to work with a TFS-hosted Git project. This allows TFS to act as a central copy of the code base, with developers merging their changes into TFS -- kind of making Git act like TFS on the server. Future TFS versions will include the full range of TFS functionality, like automated builds, via Git.
A good start
I love Git, so the marriage of it with Visual Studio was very welcome news. However, the Git integration with my copy of Visual Studio 2012 Ultimate was very slow when interacting with a Git repository -- I spent a lot of time waiting for actions to complete as the cursor sat spinning. This was true for Team Explorer options as well as context menus while editing code. A couple reboots after initial setup helped, and most of the waiting seemed to occur on startup when first accessing source control. Most often, I reverted to the command line interface, which worked without issues.
Other users reported similar issues on the download site, so hopefully these will be resolved in future versions. Maybe this is like all other first releases from Microsoft in that future versions address issues.