Announcing the Release of the Git Experience in Visual Studio

Pratik Nadagouda

We’re excited to announce that our new Git tooling is now the default source control experience in Visual Studio 2019, beginning with version 16.8. We’ve been working on this experience over the last year, iterating based on your feedback to build out key features, enhance performance, and fine tune quality. Above all, we’ve focused on improving discoverability for your common workflows and simplifying navigation to reduce context-switching. Regardless of whether you are part of a large team or working on a personal project, whether you are an experienced developer or just starting out, we strongly believe the new Git experience in Visual Studio 2019 will have something for you. Here’s seven reasons why we think you should try it out.

Git Productivity Demonstration in Visual Studio 2019 v16.8

Git Productivity in Visual Studio 2019

Redesigned Git repository creation

To get started with Git, Visual Studio lets you add your local code to Git and GitHub with a single click. The Create a Git repository dialog contains the new integrated GitHub sign-in flow, similar to what we offer for Microsoft accounts. Here, you can set the repository to be publicly visible or switch it to private. That makes it securely accessible to only you and any designated collaborators. In addition to GitHub, you can also push your code to an existing remote repository. This can be one you’ve already created on Azure DevOps or any other provider. And finally, you can choose to create a local-only Git repository if you are not ready to push to a remote host.

Image createrepodialog

Create Repository dialog

Accessible top level Git menu

You can now access your favorite Git features using the top level Git menu. It’s at easy reach through the Alt+G keyboard shortcut. This menu also has the Local Repositories submenu. By expanding it, you can easily switch between local Git repositories you have previously opened in Visual Studio.

Image 16 8 P3 reposlist

Git menu with Local Repositories list

View files in Solution Explorer

After you’ve opened or cloned a Git repository, Visual Studio helps you get straight to your code. Solution Explorer loads the root of the repository and scans the directory for any View files. Instead of having to search for your .sln file to open it, Visual Studio detects and loads the solution automatically. If your repository has more than one .sln file, then Solution Explorer shows you the list of available views to choose from. Subsequently, you can toggle between the currently open Solution (view) and the list of Views by using the Switch Views button in the Solution Explorer Toolbar.

Image 16 8 P2 listofviews

Switch Views in Solution Explorer

Streamlined inner loop Git Changes window

The new Git Changes window is designed to provide quick access to commonly used Git operations that you need while you are coding. You can create new branches, stash, stage, amend, and commit changes, all from the same place without switching pages or losing context. Moving to the top of the window, you’ll see handy fetch, pull, and push buttons. They allow you to sync commits and tags with your remotes (that’s right, multiple remotes!). The Git Changes window also has an indicator displaying the number of outgoing and incoming commits. This indicator functions as a link to take users to the Git Repository window. From there, you can view a summary of your outgoing and incoming commits before you sync.

Image gitchangeswindow

Staged Changes and Stashes in the Git Changes Window

Full screen Git Repository window

If you like browsing and managing your repository, you no longer need to leave Visual Studio. The new Git experience comes with a rich Git Repository window that makes it easy to visualize the entire history of your repository. You can right click on a branch to perform operations like merge, rebase, reset, and cherry pick. Moreover, the Repository window is accessible through the Git menu, the View menu, and the status bar.

Image GitRepoWindow

Branch History in the Git Repository Window

Enhanced merge conflict resolution

If you run into a merge conflict, Visual Studio now guides you through the process of resolving it. The Git Changes tool window clearly lists unmerged changes. Also, it displays a status message specifying that conflict resolution is in progress. Further, a gold info bar in the conflicting file prompts you to open the Merge Editor. Once you’re there, the three-way Merge Editor takes you through each conflict in the file. In other words, it allows you to compare lines and even individual word-level differences. Moreover, you can accept all current or incoming changes at the file level with a single click.

Image git merge editor

Merge Conflict Resolution with the Merge Editor

Customizable experience

We want you to be able to personalize your Git experience. To change any of your preferences at the repository level or the global level, go to Git – Settings in the menu bar. This will take you to the consolidated Tools – Options pane for Source Control.

Image Git Settings

Git Settings in Tools – Options dialog

However, if these features aren’t working out for you, it’s possible to revert back to the full Team Explorer experience. Go to Tools – Options – Environment – Preview Features and toggle the New Git user experience checkbox. Please let us know why!

Image git preview feature

New Git user experience Preview Feature flag

This is just the beginning

To summarize, from the new Git menu, you can clone, create, or open repositories. You can use the integrated Git tool windows to commit and push changes to your code, manage branches, sync your remote repositories, and resolve merge conflicts. Find the full list of capabilities in the Release Notes. Learn how to use the features in our documentation. Most importantly, join the conversation on Developer Community to weigh in on what we’re building next. And please provide feedback as we continue to enhance the Git experience in Visual Studio!


Comments are closed. Login to edit/delete your existing comments

  • Jack Bond

    The list displayed when you select “Local Repositories” takes WAAAAAY to long to load. I just tested it out, and on my beefy machine, it took over 20 seconds from after Visual Studio loaded. This was never the case in the old view.

    Will this be fixed, in the next two or three days? If not, someone should be fired.

      • Jack Bond

        Having played with it longer, sometimes the list NEVER appears. Also, how exactly does one delete and re-add a repo?

        This experience has been HORRIFIC.

        I’ll double down on my original comments, and say an entire team should be fired.

        And believe me, if it wasn’t for the code of conduct that can be summed up as “we can’t handle F bombs”, I would have been dropping a ton here.

        Seriously, is Microsoft strapped for cash? This couldn’t have gone through 30 seconds of testing or usability studies.

        • Pratik NadagoudaMicrosoft employee

          Thanks for providing more feedback, Jack. We’ve triaged and are investigating the issue. I’d like to request you to provide more information on the ticket so that our team can pick it up without delay.

          I’ve also created this feature request for deleting repos. Please vote on it to help us prioritize the work.

          And finally, thank you for adhering to the code of conduct. Some of us do find it hard to handle the F bombs. 🙂

      • Peter Xiao

        I ran into the same problem and wanted to optimize the load speed

  • Nelson Giraldo

    Excellent upgrade, I use Visual Studio all days and it’s great this integration with Git repositories 🙂

    • Taysser GherfalMicrosoft employee

      Thanks Nelson, we are happy that you like the new feature. Please feel free to let us know if you have any feedback or questions.

  • Anthony Dewhirst

    I’ve been using the git experience in preview and have gotten used to it and like it a lot.
    Showing my team how to use it, I suddenly couldn’t find the place where you link a work item to the commit. Had this moved? I was doing this on the teams window but the work items now open in a full window and I couldn’t see how you now link?

    • Taysser GherfalMicrosoft employee

      Thanks for the feedback Anthony, glad that you are getting used to the new experience. Regarding linking a work item to a commit, you can do that by writing “#” in your commit message which will provide a list of work items to chose from. You will need to be connected to ADO for this feature to work. To connect to ADO or to manage your work items, you will need to use Team Explorer (View > Team Explorer). Because we wanted to support GitHub issues, we haven’t been able to do much work to enhance the existing work items experience. More work is needed to provide a unified experience for both git providers. Please feel free to add your vote to this suggestion: link

  • John King

    I have to say I don’t like the new git design, with old Team explorer, we can use git / add /remove/ manage branch / add .gitignore / setting git global setting / manage
    git remote and more in just one place .
    today , vs make the new git Experience by default.
    but you look at it , you will find that to use git , now you need at least to know 3 place : git change + git repository + tool-setting-[source mange]- git + team explorer. what a mess !!!!!!!
    and you know what , the [git tool bar menu] —-[push to git service] only have github, do you kill devops or what?

    and Are you serious to use visual studio setting dialog to manage current workspace ? won’t this dialog is about manage visual studio ? since when the visual studio setting care about project/solution file location ?

    • Chris Schaller

      I am so confused how this made things easier… I’m with you @JohnKing, the most recent version I finally felt like things were getting better, this is such a productivity killer for my day to day, its hard to buy in to “more clicks” == “productivity”

    • Taysser GherfalMicrosoft employee

      Thanks for the feedback John, Chris, we understand that Team Explorer had a lot of great functionality that many VS users are accustomed to. At the same time we found out that a large population of our git users were complaining about how they had to jump between different pages in Team Explorer to go through their git flows. The quote that we kept hearing says “With Team Explorer you have to go to the branches page to create a new branch. Then go to the changes page to commit your changes. Then go to the sync page to pull and push, etc.” This is something we worked hard to address in the new experience. Now you can use the Git changes window for your light inner loop git operations while coding without having to switch between windows. For example, you can create a new branch, commit, and push all from the Git changes window. Then when you would like to browse your git repository and execute more complicated git commands, you can use the Git repository window where you get more screen real-estate. This is also where we will be able to add more advanced git features in the future.

      I totally understand that switching to a new experience can be hard and confusing, but we are here to help. Did you know that you can quickly access git settings through the git menu? We found that most of our git users don’t access their git settings frequently. They change their settings once and never change them again. That is why we grouped git settings with the reset of settings in VS, but made them accessible through search and the git menu.

      This is also V1 of the new git experience and we are actively working on it, so please feel free to vote for existing suggestions or create new ones using the following link: New Suggestion

      Also feel free to take a quick look at the documentation for the new experience: docs

      • John King

        but do you know the git repository windows is take area of my code area ? and “At the same time we found out that a large population of our git users were complaining about how they had to jump between different pages in Team Explorer to go through their git flows” , come on , now it’s worth , I always want VS Code can have the same git experience like visual studio. and for the issue , the solution is create inside tab for those operation, instead separate team in more place. yes , I like the git menu , but not the new Git UI experience .
        Suggestion: use git menu, plus old “Team Explorer” rename to “Source Control” , for git’s operation, use inside tab for swtich , dropdown is not so “directly”

      • Gavin

        Honestly, those seem like weak arguments for trashing the great integration with Azure DevOps that we had. This is big step backwards for those of us who value the integration between our IDEs and DevOps, just to save some people a couple of clicks. Maybe it’d be worth considering some input from people who do make use of the existing workflows?

        • Michael Bond

          I agree entirely. It seem as though they have optimised the wrong areas. I use Changes, then rarer syncing and then even rarer branching in that order. It seems as though they have tried to place Branching, syncing and changes on the same pedestal when they just aren’t used at the same rate.

          I fear for the day when Microsoft decide that we must use this newer, worse interface, and drops the superior DevOps based interface.

        • Matthew Whited

          Yep, it seems many projects and teams at Microsoft are worried about the “new shiny” versus what actually works.

      • André Silva

        I agree with others here. And I must be honest in that I think that this new UX is complete garbage. It has totally wrecked the integration with Azure DevOps, and more. Most noticeably, two things I used a lot are now broken: Pull Requests inside VS and opening the solution through Team Explorer (on a multi-solution folder). I now open VS and do not even know how to begin to open my solution.

        Terrible update. Feels like the team published before testing and/or studying the impact of their changes. This should be eligible for rollback.

        • Saji Weerasingham

          Totally agree…can’t launch Azure DevOps to create a pull request via the context-menu on a branch 😥

    • Joe Hershman

      Add me to the list of not understanding how having a UI that takes up the entire code window is an improvement. I am not sure that I see any functionality being added. About the only difference I see is the history being viewable, but I need to see history an extra context menu click is not an issue. Also as far as I can tell we are missing a Create Pull Request option

    • Patrick Harris

      I completely agree. I now have to rely on another tool to maintain a project’s git repo due to so many features being stripped out / moved around. Please do not ever take it out of preview as I will not have a way back to the preferred experience.

      • Pratik NadagoudaMicrosoft employee

        Thanks for adding your thoughts, Patrick and everyone else on this thread. We’re currently focusing on how we can fix the experience for the folks who have switched off the feature. We’ve started by collecting the large categories of missing/moved/unintuitive functionality through a quick anonymous survey. Please fill it out so we can prioritize accordingly based on your feedback. We do want to make sure the experience supports your workflows in Azure DevOps without you having to switch back to Team Explorer. Thank you!

    • Chris Quick

      Agreed. The first thing I did when I saw this — turned it off. I need to remain productive — and this experience was far too different at this point. When I’m not in the middle of having to do work, it might be fine to learn it. When new features are integrated like this one that could end up being productivity killers for users in the middle of projects — you need to have users OPT-IN to turn it on. In the middle of a big project — not a good time.

      • Darren Cook

        I agree too. I’m glad this can be turned off. I use Sync daily and could not find it with the new UI. Also, use Command Prompt which might be there in the update but could not find that either. A separate Changes window might be useful but I’ve turned it off because core elements are missing.

    • Tim Hargan

      I totally agree – the new design sucks. It was way better where all the commands could be round on the right panel – now you have to access multiple locations and bring up more windows – who wants that- the only thing that really needed to be improved was the branches view – it never was clear on the diagram which branch is which – it would be good to have lines with colors and names with the same colors for those – is that hard?

  • Alexandre Nedelec

    Pratik I like the new Git UI but it seems it seems it broke the ability to read Pull Requests directly from Visual Studio thanks to the Pull Request extension for Visual Studio. Indeed since upgrading my Visual Studio to 16.8.0 I can’t use the Pull Request extension anymore is it something you plan to correct ? This extension was highlighted on this very same blog and is maintained by Microsoft Dev Labs if I a m not mistaken.

    • Pratik NadagoudaMicrosoft employee

      Hi Alexandre, thanks for the feedback about the UI. The Pull Request extension is experimental and a part of our DevLabs initiative. As such, we’re not enhancing or maintaining the extension any longer. The reason being that it was built on top of Team Explorer, and we didn’t want to continue adding more features to Team Explorer without addressing the larger issues that we had been seeing; namely – discoverability of features, context switching for simple workflows, and steep learning curve.

      Our current approach with the new experience is based on customer feedback. If you want to see Pull Request functionality integrated into VS, please vote on feature requests such as these for creating PRs or preparing for PRs. If you don’t see an existing suggestion for your request, feel free to create a new one. This will help us prioritize the work we focus on next.

      • Dave Moyle

        You are seriously mistaken if you believe you have improved the context switching scenario. Removing a fundamental feature and making users drop back to an external CLI or some other tool is not an improvement.

        • Pratik NadagoudaMicrosoft employee

          Apologies Dave. Our intention is not to permanently remove the feature. Pull Request functionality is on our backlog and we’re iteratively building out the experience. You can follow the feature request to get updates on our next steps. In the meantime, feel free to turn off the feature to get back your regular experience, but please do fill out this quick survey to help us understand your reasoning better.

  • thomas woelfer

    So any plans to make it easy moving from vsts to git? of course i can just check in everything but we’d loose years of information about changes, comments, etc. etc.. So what are you planning to do about this?

  • Steve Higgin

    Where is the option to push to a new Azure DevOps Repository, you only seem to have push to GitHub now in the new experience, if you switch back to the old one you get Azure DevOps and GitHub push options?

    • Tim Toennies

      My question as well.. Love the interface; how can I configure it to use Azure DevOps as well?

    • Taysser GherfalMicrosoft employee

      Thanks for the question Steve, Tim, to push to Azure DevOps follow these steps:
      – Use the “Existing remote” option in the create a Git repository dialog
      – Provide a link for an empty Azure DevOps repository

      We’re monitoring a request to provide an Azure DevOps repo creation experience similar to GitHub through this suggestion ticket. Could you please add your vote to the ticket to help us prioritize this work? Thanks!

    • Thomas Elbek

      Totally agree – Microsoft just cut the throat on Azure Devops. How is it possible to create a brand new Git Experience – and forget just about everything about Azure DevOps?

      Microsoft – it’s a redo!!

  • Фарид Кадыров

    With the new Git experience I can’t see Pull Requests tab in Team Explorer window

  • Tobias Wolf

    We are working with Azure DevOps and like to associate our work items to the commits. Under the old experience this is easily done inside Visual Studio through the Changes windows. In this new Git experience, there seems no way to do that anymore. The “Relate to Changes” function in the Team Explorer/Work Items window also appears to only affect the old Changes window, but not the new Git Changes.

    Is that something on your roadmap for future improvements? Without we are likely stuck with the old system as long as it remains supported.

    • Pratik NadagoudaMicrosoft employee

      Thanks for the feedback, Tobias. We agree this is important functionality. As Taysser mentioned in another comment, we still need to work on a new design for this mechanism so that we can generalize it to work for both GitHub issues and Azure DevOps work items. We would appreciate your feedback on how you’d like to see this, please vote and comment on the suggestion ticket. We will also post our designs there once they are ready. In the meantime, as a workaround, the capability still exists, you can manually type the #number into the commit message, and the work item will get linked.

      • Luiz Fernando Bicalho

        I’m not sure if it’s configured somewhere, but if I type “#” how do I control what to show, because it’s only showing one PBI

        And would be nice to force the user to select at least one work item to commit

  • R. A. Raboud, Jr.

    SUB-MODULES, SUB-MODULES, SUB-MODULES. VS Code handles them but the premiere IDE does not. Please, please, please, look at how VS code handles sub-modules and implement something!!!!!!

    Add the missing features before inventing new ones.