This suggestion is migrated to Developer Community. Please use below link to view the current status.
https://developercommunity.visualstudio.com/content/idea/351802/team-explorer-needs-better-support-for-multiple-gi.html
Most developers have multiple accounts across VSTS and GitHub. Additionally within a single VS instance they may want to use different accounts for different sets of repositories both inside and outside VSTS. Currently you can only be signed in to a single Git account at a time. You have to remember to sign out before trying to connect to another repo that uses a different account. It seems like the account association can be managed better such that we can specify which account to use for each repo we set up (and default it to make it easier).

Furthermore if we have a large number of repos across VSTS and GitHub then Team Explorer just breaks them up by GitHub, VSTS and local repos. It would be nice if we could have some sort of way of grouping this better so that I can keep my work repos separate from my personal repos separate from my second work's repos. Right now they are all combined together making it hard to find the repos I care about.

We tag our user stories with the version of the product that they were introduced in. It can be time consuming to review changes to determine which are relevant to a particular release.

One thing that would help is to be able to filter the list of completed pull requests by date. Then we could more easily identify changes introduced to master between two known release dates.

More broadly speaking, it'd be great if we could filter user stories based on attributes of attached pull requests and vice versa. At this time, they seem to be completely unrelated, except that you can link a pull request to a work item.

Note: This is using TFS for Source Control, not Git.

I did a rollback of a changeset that removed files, because I realized we still need those files. I forgot to include the csproj in the checkin, and have added additional files since then.

If I could Include specific lines in the csproj to pending changes, then I don't have to delete those lines in the csproj to properly checkin the fix for the changeset above, while not polluting the checkin with irrelevant changes.

All git committing clients support this, by using `git add -i` or Git Extensions allows for GUI interactivity for "Include Selected Lines" and allowing for a partial file checkin.

Please add this to your TFS client

More often than we would like we find that something went wrong in a previous merge that caused incorrect changes to be checked in. We would like a method to review the merge after the fact so we can identify the cause and apply any corrective actions that are required.
This could be turned off via a setting, but we should be able to make this merge log be a mandatory part of a check-in.
This would require the TFS tools to detect that a merge was required and flag the checked out file in the user's workspace that the merge was needed.
The following are the needed steps for this:
1. Detect that there is a merge conflict in the workspace for a specific file and set a flag it that indicates this.
2. Record the two sources and the result of a Merge (a "log") when a merge conflict is resolved. This should be able to handle multiple merges that occur during a single checkout (the extreme case).
3. Store that data in TFS when the merged file is checked in. Clear the merge conflict flag at that time. If a merge "log" is marked as mandatory then fail the check-in if the "log" is missing.
4. Allow users to open the data to show the applied merge results, and to compare either source of the merge to an existing version. This should be able to be done even if the file has not yet been checked in.