Enhanced Productivity with Git in Visual Studio
We continue to enhance the Git experience in Visual Studio and are excited to announce some long-awaited updates in version 16.10 Preview 2. You can download the latest Preview and run it right alongside your main release, leaving your production installation undisturbed.
In the last iteration, 16.9, we listened to your feedback and focused on fixing issues after the first public release of the Git experience. In 16.10, we’ve built new functionality that addresses gaps around discoverability, switching repositories, navigation, and more!
The first set of changes is to the status bar. The section of the status bar at the bottom right of the IDE window has a tray of always accessible Git commands. And we started to expand the functionality there.
Beginning with the rightmost button, the well-known branch picker now looks similar to the branch drop-down in the Git Changes window. With this visual overhaul, you’ll have access to search branches and can view both local and remote branches. The context menu gives you actions to perform on a branch, regardless of which tool windows you have visible.
Branch picker in the status bar
The repository button in the status bar now has the first iteration of a repository picker when you select it. You can see all of your local repositories sorted in alphabetical order, and you can filter the list, too. Soon, you’ll be able to remove items from this list as well.
Repository picker in the status bar
Whenever you open a version-controlled folder or solution for the first time in Visual Studio, you’ll see the associated Git repository appear in your local repositories list along with any of its nested sub-repositories. If the remote of the repository is hosted on Azure DevOps, you’ll get a prompt in Git Changes to connect to the Azure DevOps Project. Doing so will allow you to access Work Items and Builds for the project. And after the initial connection is established, Visual Studio remembers it so that it auto-connects the next time you open the repository.
Info bar to establish initial connection to Azure DevOps project
By default, whenever you open a repository, Visual Studio loads the associated solution/folder in Solution Explorer. If you have multiple solutions in the repository, then Solution Explorer displays the list of solutions.
List of solutions for the repository in Solution Explorer
Customize repository behavior
There are a few nuances here. Normally, Visual Studio will maintain consistency between the open repository and the open solution so that they are never out of sync. For example, if you switch to a different repository, then the open solution will close and the new solution will open. But we’ve seen situations where your solution might be outside of your Git repository. If so, you’ll want to keep the solution open when you open a repository even though they’re in different folders. Now, you can customize that behavior by toggling the new preference in Git > Settings.
Preference to choose whether to close solutions when switching repositories
We’ve also gotten feedback that some developers prefer to use Visual Studio as a Git tool before they start coding. For example, you might want to change branches or pull commits before you open a solution or folder. Our first step to help here is to provide an option to open only a repository, and not any code files with it. This will make Visual Studio essentially a Git-only tool. If you want to open code files, then you can load the solution or folder later.
Preference to load code when opening repositories
The Changes button in the status bar shows the number of changed files that haven’t been committed yet. It provides a shortcut to open the Git Changes window.
Button to open Git Changes window
And the final button in the status bar shows your Git remote operations. This button displays the number of commits that haven’t been pushed to the remote. And soon, it’ll also show you the number of unpulled commits. When you click this button, you’ll see a new flyout with commands to Fetch, Pull, Push, and Sync (which we brought back by popular demand)!
Outgoing / Incoming commits dropdown with Sync functionality
Sync is short for Synchronize and is a combination of a Pull and then a Push. The added benefit of the Sync command is that it synchronizes your local branch with the remote in one click. The command is also available in the top-level Git menu, which allows Sync to have its own keyboard shortcut (Alt+G+S) for quick access. It also makes it searchable in the Ctrl+Q search box, if you ever forget where it is.
Sync command in the Git menu
Git Repository window
The first thing you’ll notice in the Git Repository window is the permanent home for the list of Incoming and Outgoing commits. You can now access these sections from the status bar and keyboard shortcut Ctrl+0+Y. The sections give you an overview of all the commits that are yet to be pushed or pulled. When you select Fetch, it will populate the Incoming section. Making local commits will populate the Outgoing section.
Fetch, Pull, and Push buttons in the permanent Incoming and Outgoing sections in the Git Repository section
Embedded commit details
The next thing you might want to do after looking at an outgoing commit is to check what changes were in the commit. Previously, selecting a commit would open a new tool window, and then selecting a specific file to view the changes would open yet another window. That’s too many windows! So, we embedded all the functionality into one single window. You’ll be able to see the details of the commit and a visual of the changes in the first file. You can go down the list of files and view the changes in each file right there. The windows work in the same way when comparing two commits.
Embedded commit details and inline file diff in the Git Repository window
And if you want to get a full screen view of the commit details, maybe even pop out a few different commits on different screens to deep dive into the changes, you can do that too! You have full control over the layout of the window.
The toolbar at the top of the file comparison provides you with useful information. The notations on the left tell you the number of deletions and insertions in the file for the selected commit. By using the actions on the right, you can change the layout from side-by-side view to inline view and others.
Popped out tab for commit details with side-by-side file diff
Git Changes window
We’ve consolidated the buttons in the status section of the Git Changes window into a single overflow menu in the upper right corner. From here, you can manage multiple remotes if you have any and perform actions on them. The menu also gives you access to commands for navigation and opening other windows related to your repository such as Settings, Branch History, File Explorer, and Command Prompt.
Action menu in the Git Changes window
With every new experience, there’s always a change in muscle memory. We think it’s important to provide up-to-date guidance on how to use any new tooling. For that purpose, we’ve created a free online course to learn Git in Visual Studio with step-by-step exercises. Our documentation is also updated with more articles on version control.
Regardless of whether you’ve followed along with our journey from the beginning or are joining us right now, just know that there’s much more to come. We have plans to build many valuable features to help you work with Git repositories in Visual Studio. To help us prioritize, please continue to vote on feature requests, and let us know how we’re doing!
You know what would really be great for git productivity?
Submodule support https://developercommunity2.visualstudio.com/t/full-git-submodule-support/351549?from=email&viewtype=all#T-ND1340880
Which has been on the “roadmap” for years, and developers have been asking for too. Stop rewriting the basic git experience to make things nicer and start including this which is something developers are really blocked by!! Being able to switch to a branch or repo easier is NOTHING compared to having no version control AT ALL
If you did not know, please, read the stories, spread the word.
If you don’t like clicking links, this is my last reply from the last time the “git experience” was rewritten, in November:
“I really wonder how many people actually care about the feature parity with TFS, or redesigned workflow of Git stuff (like the last updates), while in fact not supporting submodules properly breaks the experience constantly.
For example: Viewing the history of an item that’s located in a submodule? Not possible. Viewing changes made in submodule (even if by accident)? Not possible. Pulling changes from submodule? Not possible. Switching branch of submodule? Not possible. Solving conflicts in part of submodule? Not possible.
There is SO MUCH to be gained here. We have to resort to 3rd party tools for this, and that still requires switching between applications constantly, and having multiple Visual Studio instances open to tackle conflicts. Not very practical, especially on 1 screen.”
(That post alone got 26 upvotes from devs that have not given up shouting for this)
I know it’s easier to pick up dev things that you like to implement and are in line with the simple design that was set out with, and this won’t be easy. But the longer this is ignored, the harder itll become to implement. We’re all devs here, we all know this. Stop dreaming, start building. Please!!!!
Yes absolutely, you’re right in all your points. It’s a tough, complex problem to solve. And we’ve started down that path by first tackling multi-repo support. We believe that will lead directly to a great submodule experience.
Thanks for the most useful answer in years! 🙂
I hope at least History/Git log support of files in submodules is implemented first. But the complete package would be amazing.
If you need inspiration: In our opinion at least the GUI experience of SmartGit works for us (so basically using colors to indicate part of submodules are in a different state than referenced by the parent repo, and an easy way to restore this)
Yes, we need submodules support, please.
As already described by Joris Kommeren, we also use multiple Visual Studio instances with submodules loaded together with external batch scripts and git tools to even make the work possible.
How to find all git tag
We don’t have a tags list yet. What are you exactly trying to do with a tag? We have open feature requests related to searching for tags in the Git Repository window or pushing individual tags. Let me know if it’s something else, and I can open a suggestion ticket.
Will this new version finally allow you to create a remote repo on Azure DevOps in the dialog you get when you first check your solution into source control locally, whereas today you only get the choice to use Github, whereas before the git experience you used to be able to choose from both?
Ah, we’ve not gotten to that yet. For reference, here’s the feature request.
Embedded commit details are great! Thanks.
Full history view also would be nice.
Glad you like it! Multi-branch history view is a feature request that we’re tackling soon.
I disagree strongly.
Any hope that the “Embedded commit details and file comparison in Git Repository window” functionality gets an option so it can be reverted to (the superior) pre-16.10.0 behavior? (I have no idea where to suggest such a thing; I don’t know which “voice” site works this week, or even if that paradigm has changed again.)
1. I can no longer use my differencing engine of choice; the built-in one is significantly inferior to my external tool.
2. Changing it a document-window instead of a docked tab adversely affects my workflow; it slows me down and makes things more confusing. When I view a commit or changes between 2 selected commits, it is a tangential/augmentative action, not axiomatic. Forcing it to overtake my main window pane (which is usually history) removes/hides contextual information from the UI, significantly complicates the [Ctrl]+[Tab] state. And depending on the situation, the mouse travel is greater, which increases physical RSI concerns with my hands (E.g. the diff area is horizontally limited now because it shares window pane space with the rest of the VS workspace layout).
One minor but important issue, I always run into is, whenever I make git changes outside visual studio, the branches window refreshes by first clearing the commits list and repopulating it. I would like to see it update the existing view by just adding/removing/updating the commits.
Thanks for the feedback. I can understand that it feels slow because of the refresh. I created a feature request to help us track improving the perception of speed in that experience. Please vote on it.
With exception of poor tags support, I am loving this new experience! Do you know if there will be any support for deleting branches in batches? Branch cleanup is such a chore and traditionally one of the most painstaking parts of Git. Having a multi-select of branches for bulk deletion would make this very easy.
Thanks! We’re thinking of possibly introducing the functionality alongside multi-branch graph. But the specific feature suggestion for deleting multiple branches needs some love. Please upvote!
Also would be helpful if you could specify what exactly you want to do with tags in a new feature request. You do already have the ability to create and push tags in VS.
I like side-by-side diff. It would be nice if you can make it editable on the right side.
Thanks for the feedback, I would have thought we already had this feature request but I couldn’t find it. So I created a new one for you to vote on.
PLEASE make sure to add the ‘Sync’ button back into the ‘Git Changes’ window right next to the other buttons (Fetch, Pull, Push). As mentioned in the suggestion that spawned this feature, this is where many of us developers live and a similar button exists in the current ‘Team Explorer’ window that was used before the ‘Git Changes’ window was created.
It’s coming 🙂
in Team explorer i can merge from master to branch in just 2 clicks. With Git expirience i need use bash? Some useless innovation…
Hi Oleh, you shouldn’t have to use bash. Have you tried using the new branch picker or the Git Repository window branch list?