Category Archives: Git

How To : Use Git Tools for TFS Integration

Git – TFS Integration – Why it matters

 taking-your-version-control-to-a-next-level-with-tfs-and-git-1-638[1]

For many small development shops, the idea of using TFS and a centralized source control repository is anathema. The mere thought of being restricted by a software configuration manager on how and when to branch or merge cuts against everything they cherish in software development.

 

Git is their natural and chosen ground for managing source code. The freedom and flexibility of using Git enables them to work where they are. This is especially true if they are working as part of a distributed team on modular projects.

Microsoft addressed many of the existing concerns with TFS source control with the advent of TFS 2012 and local workspaces. However, even though local workspaces enable great flexibility in offline work, they are still ultimately tied to a central repository and the policies and restrictions imposed on it.

 

Enter Git support in TFS. Git support currently comes in two forms; stand alone Git support in Visual Studio and Git support with TFS.

Git support with Visual Studio is completely straightforward. Simply change the source control plug-in selection to the Microsoft Git Provider and all the power and flexibility of Git is available to the Visual Studio developer such as private branches and online collaboration with Git hosts such as GitHub and BitBucket.

Source

Configuring Git for Visual Studio Source Control

However, from an ALM perspective, the real power and the compelling feature of Microsoft’s integration with Git is the ability to work with TFS.

 

Developers still get all the advantages and flexibility of Git, but can also take advantage of the ALM features of TFS such as work item tracking, team tools and integrated build. The Git – TFS integration gets us much closer to the ultimate goal of true cross-platform support in a single ALM toolset.

 

The TFS – Git integration can be utilized a couple of ways. The first option is the ability to essentially synchronize a Git repository with TFS source control with the Git-TF utility. This utility makes it easy to clone sources from TFS, fetch updates from TFS and push changes back to TFS.

 

What’s more, it fully supports TFS shelvesets and work item integration, which presents some exciting possibilities. The features and functionality Git-TF provides makes it a compelling solution and a credible compromise between centrally managed teams with source control and distributed teams with distributed source control.

The second option, available now only through Microsoft’s hosted TFS Service, is the ability for organizations to create TFS Team Projects with Git hosted source control (this ability is reportedly planned for on premise TFS support in the next release). This is a fairly exciting development.

 

Having the choice between native TFS version control and Git when creating a team project opens many doors that hitherto were locked shut.

remoteRepo1

XCode IDE connected to a TFS hosted repository

Eclipse, XCode, Visual Studio and any other IDE that supports Git can now be used to leverage the powerful ALM features TFS provides.

As an ALM consultant, that’s the part that excites me the most. Hosting all development efforts in a single environment; an environment that supports all the various technologies in play and being able to track and manage those efforts with agility and transparency is a huge benefit to any organization that provides multiple platform solutions.

 

Even those who don’t, will now have the option to at least evaluate the feasibility of utilizing TFS in development environments not typically associated with a Microsoft project.

The mythical promised land of cross-platform ALM may have just become quite less mythical.

 

———————Microsoft’s Tool for Git and TFS Integration – ———————————————————————–

 http://gittf.codeplex.com

2352.vs_5F00_heart_5F00_git_5F00_thumb_5F00_66558A9C[1]

Working with Teams

The Git-TF tool is most easily used by a single developer or multiple developers working independently with their own isolated Git repos. That is, each developer uses Git-TF to clone a local repo where they can then use Git to manage their local development that will eventually be checked in to TFS. In this “hub and spoke” configuration, all code is shared through TFS at the “hub” and each developer using Git becomes a “spoke”. Developers looking to collaborate using Git’s distributed sharing capabilities will want to work in a specific configuration described below.

Most often, developers collaborating with Git have cloned from a common repo. When it comes time to share divergent changes, conflict resolution is easy because each repository shares the same common base version. Many times, conflicts are automatically resolved. One of the keys to this merging of histories is that each commit is assigned a unique identifier that is generated by the contents of the commit. When working with Git-TF, two repositories cloned from the same TFS path will not have the same commit IDs unless the clones were done at the same point in TFS history, and with the same depth. In the event that two Git repos that were independently cloned using Git-TF share changes directly, the result will be a baseless merge of the repositories and a large number of conflicts. For this reason, it is not recommended that teams using Git-TF ever share changes directly through Git (i.e. using git push and git pull).

Instead, it is recommended that a team working with Git-TF and collaborating with Git do so by designating a single repo as the point of contact with TFS. This configuration may look as follows for a team of three developers:

          [TFS]      [Shared Git repo]
            |         ^ (2)  |       \
            |        /       |        \
            |       /        |         \
            V (1)  /         V (3)      V (4)
       [Alice's Repo]   [Bob's Repo]   [Charlie's Repo]
 

In the configuration above the actions would be as follows:

  1. Using the git tf clone command, Alice clones a path from TFS into a local Git repo.
  2. Next, Alice uses git push to push the commit created in her local Git repo into the team’s shared Git repo.
  3. Bob can then use git clone to clone down the changes that Alice pushed.
  4. Charlie can also use git clone to clone down the changes that Alice pushed.

Both Bob and Charlie only ever interact with the team’s shared Git repo using git push and git pull. They can also interact directly with one another’s repos (or with Alice’s) , but should never use Git-TF commands to interact with TFVC.

When working with the team, Alice will typically develop locally and use git push and git pull to share changes with the team. When the team decides they have changes to share with TFS, Alice will use a git tf checkin to share those changes (typically a git tf checkin –shallow will be used). Likewise, if there are changes that the team needs from TFVC, Alice will perform a git tf pull, using the –merge or –rebase options as appropriate, and then use git push to share the changes with the team.

Note that (until Issue 77 is addressed) all changes coming into the TFVC repository will come in as if from Alice’s TFS identity. This is fine if only Alice has an identity on that TFVC project but it may well not be what you want if Bob and Charlie also had valid identities in that TFS project.

Rebase vs. Merge

Once changes have been fetched from TFS using git tf pull (or git tf fetch), those changes must either be merged with the HEAD or have any changes since the last fetch rebased on top of FETCH_HEAD. Git-TF allows developers to work in either manner, though if the repo that is sharing changes with TFS has shared any commits with other Git users, then this rebase may result in significant conflicts (see The Perils of Rebasing). For this reason, it is recommended that any team working in the aforementioned team configuration use git tf pull with the default –merge option (or use git merge FETCH_HEAD to incorporate changes made in TFS after fetching manually).

Recommended Git Settings

When using the Git-TF tools, there are a few recommended settings that should make it easier to work with other developers that are using TFS.

Line Endings

core.autocrlf = false

Git has a feature to allow line endings to be normalized for a repository, and it provides options for how those line endings should be set when files are checked out. TFS does not have any feature to normalize line endings – it stores exactly what is checked in by the user. When using Git-TF, choosing to normalize line endings to Unix-style line endings (LF) will likely result in TFS users (especially those using VS) changing the line endings back to Windows-style line endings (CRLF). As a result, it is recommended to set the core.autocrlf option to false, which will keep line endings unchanged in the Git repo.

Ignore case

core.ignorecase = true

TFS does not allow multiple files that differ only in case to exist in the same folder at the same time. Git users working on non-Windows machines could commit files to their repo that differ only in case, and attempting to check in those changes to TFS will result in an error. To avoid these types of errors, the core.ignorecase option should be set to true.

Advertisements

How To : Set up Git on your dev machine (configure, create, clone, add)

Git-Logo[2]Applies to : Visual Studio 2013

When you start using Visual Studio with Git, choose the way that works best for you and the kind of project you’re working on. For example, you can start an experimental solo effort in a new or an existing local repository and continue developing there as long as you want.

Or you can join a collaborative effort in a remote Git repository, hosted either in Team Foundation Server (TFS) or on another service.

Before you start

What do you want to do?

Start from a local repository


You can create a local repository on your dev machine—whether or not you have a network connection—and start developing right away: coding, committing, branching, and merging code. When you’re ready to collaborate with your team, you can publish one or more branches from your local repository into a team project.

Create a new solution under local Git version control


You’ve got an idea for a new app, so you want to experiment on your dev machine. In less than a minute you can use Visual Studio with Git to create a new code project under local version control. (And no Internet required!)Create a new code project (Keyboard: Ctrl + Shift + N). We suggest that you put your new project in c:\Users\YourName\Source\Repos\.

New Project Choose Git Source Control

Put an existing solution under local Git version control


You’ve already got an app in progress and you want to start working on it under local Git version control.
Tip Tip
Before you add the solution to Git version control, we recommend you first move the solution to the TFS Git default location: c:\Users\YourName\Source\Repos\
  1. If you have not already done so, open your solution, (Keyboard: Ctrl + Shift + O) and then open Solution Explorer (Keyboard: Ctrl + Alt + L).
  2. Add your solution to source control.Adding a solution to version control
  3. On the Choose Source Control dialog box, choose Git.
  4. Now that your repository is created, you are ready to commit your files. Go to the Changes page (Keyboard:Ctrl + 0, G) and commit.Open changes page

    Committing the new solution(If you are prompted to configure your user name and email address, do that now. See Configure Git settings.)

    The commit succeeded

 

You can create an empty local repository and add files later. It’s possible to track your changes to the files whether or not they are part of a solution. Or, if you already have a local repository, just start working with it in Visual Studio.Open the Connect page (Keyboard: Press Ctrl + 0, C).

Team Explorer Connect pageTo create an empty local repository, choose New. To open a local repository that already exists on your dev machine, choose Add.

Creating a new local Git repositorySpecify the local path and then choose Create or Add.

Publish your local repository into TFS


When you are ready to share your code and collaborate with your teammates, publish your local repository intoTFS.

  1. Make sure you have committed all your changes in the local repository. See Manage and commit your changes.
  2. If you haven’t already done so, create a new a new team project (choose Git version control) or create a new Git repository in an existing Git team project.
  3. From the Connect page (Keyboard:Ctrl + 0, C), connect to the empty Git repository and publish the local repository to it.Publishing a local repository into TFS

 

Your friends have invited you to work with them on a new project. Or maybe you are setting up a new project or a new dev machine. You can use Visual Studio and Git to collaborate on TFS (on-premises or in the cloud), on CodePlex, or on a third-party service such asGitHub orBitbucket.What do you want to do?

 

If you haven’t already done so, go ahead and create or get access to a Git team project.From Visual Studio: Go to the Team Explorer Connect page (Keyboard: Press Ctrl + 0, C) and then connect to the team project.

Connect to the Git team project(If the team project you want to open is not listed, choose Select Team Projects and then connect to the team project.)

From the web: Open a team project from its home page in your web browser (Keyboard: Ctrl + 0, A).

Open a team project from web accessAfter you connect to the Git team project, if you have not already done so, you must clone it to your dev machine before you can work in it.

Prompt to clone the remote repository

Cloning a Git repository in a team projectJust specify the local path and choose Clone.

Clone a remote Git repository from a third-party service


Does your team have some code in GitHub or another service such as CodePlex or Bitbucket? To start working in Visual Studio, clone the code to your dev machine.Cloning a remote third-party repository

Note Note
You can use Visual Studio’s Git capabilities with services other than TFS. However, if you use these repositories, you will not be able to use TFS features such as project planning and tracking and Team Foundation Build.

 

To customize your Git settings, you must be connected to a local or remote Git repository. Open the Git Settings page.Opening the Git Settings page

  • Apply global settings Apply global Git settings to control aspects of how Git functions for the current user on the dev machine. For example, you can specify how you identify yourself on the changes you commit.
  • Apply repository settings Apply settings to control how Git functions in each individual local repository on your dev machine. For example, you can fine tune how the system blocks clutter from entering your user experience and repository.
  • Apply more settings Visual Studio respects all Git settings but provides you with control over only a few of them. Use the Git command prompt to customize all Git settings.

 

Git global settings User Name and Email Address: Git associates each commit you create with your name and email address. When you start using Visual Studio with Git on your dev machine, if you connect to a Git team project first, then Visual Studio fills in your name and email address for you.Default Repository Location: Specify the default root directory where you want to create or clone new local Git repositories.

Author images: Use images to more easily see the author of each commit.

  • If your Git repo remote origin is in a TFS Git team project, team members can specify their images in their TFS profiles. How? See tips below.
  • If your Git repo remote origin is in a non-TFS Git service (such as CodePlex, GitHub, or Bitbucket), select Enable download of author images from 3rd party source, and then ask team members to set up Gravatar accounts for their email addresses.
Note Note
Enable download of author images from 3rd party source also works for TFS Git team projects in cases where the author has not supplied a profile image.

An example of how author images enhance the collaborative experience:

Git author image examples: branches and history

 

Adding Git repository setting files If your repository does not have settings files, you should probably use Visual Studio to add some default files that apply the most typically useful settings. You’ll avoid distraction and potential clutter in your repository from non-source files such aslocally-built binaries..gitignore file: See Use the Git ignore file to avoid file clutter in your work and in your repository.

.gitattributes file: To specify options such as how the system handles line-breaks, specify a .gitattributes file. See Customizing Git – Git Attributes

 

Commit your repository settings files: In most cases you should commit and push these files so that everyone else on your team uses the same repository settings on their dev machines.

Committing settings file changes

Apply more Git settings


You can specify three kinds of Git settings, listed in order ofsupersedence:

  • Repository settings apply to the work done in the local repository.
  • Global settings apply to the work done by the current user on the dev machine.
  • System settings apply to all work done on the client dev machine. (Visual Studio respects these settings, but does not expose them.)

If you need to modify system settings, or if you prefer the command prompt, then modify your Git settings from there. See Work from the Git command prompt, Customizing Git – Git Configuration, and git-config command.

Q & A


Q: I’m really new to all this. How can I get more help?


A: Follow a step-by-step walkthrough to get started using Git to work locally on a new project and then to begin collaborating with a team on Visual Studio Online.
A: In most cases, it’s best to use a short, understandable folder path. For example: C:\Users\YourName\Source\Repos\FabrikamGit\SolutionName\.Some tips on effective folder names:

  • Keep all folder, sub-folder, and file names short to simplify your work and avoid potential long-path issues that can occur with some types of code projects.
  • Avoid whitespace if you want make command-line operations a little easier to perform.
A: If your Git repo remote origin is in a TFS Git team project, you can specify your images in your TFS profile from your web browser (Keyboard: Ctrl + 0, A).On the Home page, choose Web Access My Profile link on Account menu

A: Yes, any contributor to your team project can claim any user name and any email address they want when authoring a commit. However, TFS does authenticate who pushes the commit. To see who pushed a commit, open your team project in your web browser (Keyboard: Ctrl + 0, A). Open the commit you want to examine from the Commits section, and then expand the commit details.

Commit 'Pushed by" field

A look at the new features of Visual Studio 2013 – Part 1 : Git for TFS 2013

This is a mini series of blog posts looking at the various new functionality of

Visual Studio 2013

Part 1 : Git for TFS 2013

One of the great new features of TFS 2013 is the addition of Git as a source code repository.

Git is a Distributed Version Control System (DVCS) that has gained a lot of popularity in the past few years.  Git allows you and your team to work completely disconnected by keeping a copy of your source code locally, including all your change history.

By doing this, you are able to commit your changes locally, do file comparisons, create branches, merge your code, and much more.  Once you are ready to share your changes with the rest of the team, you are able to push your changes to the centralized Git repository contained in your TFS Server.

Git is not replacing Team Foundation Version Control (TFVC) but it does give you another option for you and your team to use.

So starting with TFS 2013 and Team Foundation Service, when you create a new Team Project, you are able to decide what source control repository you will use.

Implementation

TFS’s Git implementation is based on msysGit so this is not just a small subset of Git functionality.  If you are already used to working with Git, you should be able to get up and running quickly.

Even though the Git commands that you will use are the same as other Git implementations, the backend is very different.  As you may know, Team Foundation Server uses SQL Server to store all of its data, and TFS Git is no exception.  This means that your backup and restore procedures won’t change whether you are using TFVC or Git.

This implementation also means that all the integration points that you have when using TFVC are also available when using Git.  This includes Work Item associations, build integration (Continuous Integration, Gated Builds, Associated Changesets in the Build Summary), alerts, and more.

Getting Started

Before you get started, you have to create a Team Project that uses Git for Source Control.  To do so, you follow the same steps as you would normally follow to create a Team Project from Team Explorer, but you will now see a new step called “Specify Source Control Settings” which will allow you to pick between Team Foundation Version Control and Git.

As described in this step: “Git is a Distributed Version Control System (DVCS) that uses a local repository to track and version files.  Changes are shared with other developers by pushing and pulling changes through a remote, shared repository.”

Once you get through the Team Project creation wizard, you will now have a fully-working Team Project with all the great features that you are already used to (and some new ones with 2013), but instead of using TFVC you will now use Git.

Working with Git from Visual Studio 2013

When you open Visual Studio and connect to your Team Project, Team Explorer will look and behave differently since it is aware that you are using Git.

This is what Team Explorer looks like when you connect to a Team Project that uses Git:

Before you can start working with any code stored in TFS, you have to clone the repository (see highlighted link above). This creates the mapping between your local Git repository and your Git repository that is hosted by TFS.

Clicking on the link allows you to specify the location of the server repository and initializes your local repository:

As part of your local repository initialization, you will see a hidden .git folder, and two files used by Git: .gitattributes and .gitignore.

You can now get started with either a brand new project (in my case I don’t yet have anything in TFS) or making changes to existing projects.

When you are done with your changes, you are able to access similar features than what you would get when working with TFVC, except that the workflow changes.  Git expects you to commit locally at least once and then you would push those changes to the server.

Since your commits don’t affect the rest of your team until you push them to the server, you should feel encouraged to commit often since Git makes branching, merging, and rollbacks a very trivial process.

When you are ready to commit, you are taken to the  “Changes” tab in Team Explorer.  Here, you can enter a comment, select your included changes, and associate your commit to a Work Item:

You can create associations two different ways.  You can either select the “Add Work Item by ID”, the way you are probably used to doing it. Or, as part of your comment, you can enter the Work Item ID prepended by a hash-sign.

For example, in my comment above, I’m associating my commit to Work Item ID 2 by entering my comment like this: “Created new project #2”.  One of the reasons for this feature is that in some cases, your team members may need to access your source control from outside of Visual Studio, for example, by using the Git’s command-line support, and this allows you to still create associations with your TFS Work Items.

You can now push your changes to your server by accessing the Unsynced Commits tab in Team Explorer. You can access it from the link in the Changes tab or from your Team Explorer home.  When you get there, you will see a list of all your local commits.

Before pushing your changes to the server, you should submit a Pull request, which will allow you to resolve any conflicts with changes made by the rest of your team.  Once those conflicts are resolved, you can proceed with a Push operation, which will move all your local commits to the centralized repository.

Once you push your changes to the server, you are able to view History by selecting the “View History” option from the “Actions” dropdown in the Unsynced Commits tab.  Double-clicking on one of the Changesets in the history window brings up the Commit Details, which shows you my commit comment,  Related Work Items (remember that I used the hashtag to associate), and the files that were affected.

Branching

One of the most important features of Git is its ability to painlessly create branches and merge between your branches.

Since these operations are performed locally, you don’t need any special permissions to perform them in your local repository.  Team Explorer gives you an whole section dedicated just to branching:

From here you can create new branches, merge between them, view Unsynced changes in each branch, and publish your branches to your local repository.

Creating a Branch:

Merging between branches:

Build Integration

Just like when you are using Team Foundation Version Control, you are able to get full integration with the TFS automated build system.  When setting up a Build Definition, you are able to specify your repository name, the Branch that should be used to pull code from, and you are even able to pull code from a Git repository outside of TFS.

The Build Process Arguments are also a little different since you are now dealing with a different structure than you would when connecting to a TFVC repository, but once you configure the build, all build operations work the same as they would in prior versions of TFS.

This is an awesome new addition to TFS, which will give you and your team another option for source control.  If you have team members working outside of Visual Studio, they are able to connect to Git from their favorite Git plugin and collaborate with the rest of the team.

The greatest part is that all the integrations that we all love about TFS is still there, so you get all the great features of Git while being able to collaborate with the rest of the team using Work Item Tracking, Build Integration, Microsoft Test Manager, and more.

Now go out and give it a try!