Announcing the Release of the Git Experience in Visual Studio

Avatar

Pratik

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!

86 comments

Leave a comment

  • Avatar
    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.

      • Avatar
        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.

  • Anthony Dewhirst
    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?

  • Avatar
    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 ?

    • Avatar
      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 Gherfal
      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

      • Avatar
        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”

      • Avatar
        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?

        • Avatar
          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.

      • Avatar
        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.

    • Avatar
      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
      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.

  • Avatar
    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.

    • Avatar
      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.

  • Avatar
    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?

  • Avatar
    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.

  • Avatar
    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.