You’re a .NET developer with a busy morning, and an Azure DevOps ticket drops: “Login endpoint 500s under load.” You’ve got to fix it, review a teammate’s feature branch, and keep your repo clean – all before lunch. Visual Studio’s Git tools turn this everyday Git workflow of creating topic branches, stashing changes, committing, and handling PRs into a smooth, fast process.
Let’s walk through your morning, showing how Visual Studio keeps Git friction out of your way.
9:00 AM: Spin up a topic branch for your bug fix
Your repo’s open in VS (View → Git Repository), and you’re on main, fresh from last night’s CI run. To keep your bug-fix isolated, you right-click main in the Git Repository Window, select New Local Branch From, and name it fix/auth-race-1, linking it to your DevOps ticket. You’re switched to the new branch instantly, and the 2026 Git status bar shows your branch and sync status, so you’re never lost.
You update AuthService.cs with an async lock to fix the race condition.
A Slack ping from the PM interrupts: they need you to review a feature branch for a demo. Time to pause your work without losing it.
9:30 AM: Stash changes to juggle tasks
You’re mid-fix with unsaved changes, not ready to commit. In the Git Changes Window (View → Git Changes), you select your modified files, click Stash All, and add a note: “WIP: Auth fix before demo.” Visual Studio shelves everything, leaving your directory clean.
Branch switching in Visual Studio is a lot faster now thanks to optimized solution load and indexing. You polish the feature and push it to remote, all while your bug fix stays safely stashed.
With the feature review done, you’re ready to return to your bug fix and polish it before committing.
10:15 AM: Pop stash and review code
You switch back to fix/auth-race-1, and Visual Studio’s fast branch switching keeps you moving. To restore your work, go to Git Changes Window, hit the Stash tab, right-click, and select Pop Stash. Your changes come back seamlessly.
Before committing, you want to catch any slip-ups. In Git Changes Window, click the Copilot Code Review button. Copilot scans your diff and leaves a few comments in the editor. You apply the suggestions with one click.
For extra confidence, open Copilot Chat (View → Copilot Chat), type “#changes Check security,” and get: “Add rate limiting for brute-force protection.” You tweak the code, catching more issues early, which makes your eventual PR cleaner.
With your code polished, you’re ready to commit your changes.
10:45 AM: Time to commit
Your code’s solid, so it’s time to commit. In the Git Changes Window, click the Generate Commit Message button. It’s formatted to your team’s standard (learn how to set that up in an earlier blog post), tied to DevOps, and saves you a minute. Push your changes with a click, keeping your history clean and team friendly.
Now it’s time to share this with your team.
11:15 AM: Create PR and review inline
Your work is now ready for a review! Upon pushing, you get a banner in the Git Changes window and click the link to create a pull request. (Alternatively, you can also go to Git Repository Window and right-click fix/auth-race-1 → Create Pull Request.) In the PR creation UI, select your lead, Sarah, and another teammate, Mike, as reviewers by clicking the Add Reviewers field and choosing their names from the dropdown. Since there’s just one commit, VS automatically pulls Copilot’s commit message into the Azure DevOps PR description. You could also generate a PR description to ensure it matches your team’s standards. Click Create, and it’s up for review.
Sarah can easily review the PR right in Visual Studio, finding it assigned to her in the Git Repository Window.
She opens the PR and adds comments directly inside Visual Studio. The Markdown renders right in the diff, threaded and clear. No browser tabs needed!
You reply inline, make updates, and push your new changes. Visual Studio syncs the diff instantly. Reviews feel less cluttered, and Sarah and Mike approve. You merge to main and delete the branch to keep the repo clean.
Wrap-up: Git that flows
Visual Studio’s Git tools – fast branch switches, visual diffs, Copilot commits, AI reviews, inline comments – save you time in your daily grind. Branching, stashing, and PRs are smoother than ever before, letting you focus on code. The AI review before committing catches mistakes early, setting your PRs up for success.
To see these features in action, watch this Visual Studio Toolbox episode with Leslie Richardson and Leah Tran.
Try it out and let us know what other Git topics you want to know more about in the comments below.
Happy coding!
Be amazing if it could use a “git worktree” — and any .env files, settings, etc. that aren’t “git tracked” are populated over in that worktree location. Far more “isolated” and less prone to pollution if there is well known to the Developer what is being brought over for configuration vs. what is secretly behind the scends and often hidden by the IDE.
After I have reviewed a PR, how can I approved it or reject it or wait for author? And also, how can I add a required reviewer?
As I have replied below this, we use VS 2026 Enterprise 18.1.1 but in Git Repository view there isn’t the Pull Requests list, even if in devops browser I can see the PR assigned to me.
There is some specific permission or configuration to view PR list or something else?
I understood that was a problem in our azure devops repo, because I succeded to create a PR in another repo.
Some improvements could be:
– chance to choose if the revisor is required or optional
– chance to change the PR state in accept or reject or wait for author directly from VS
– chance to view the PR assigned to me and it being notified about new assignment or similar
Too bad creating PRs in Visual Studio is not available for Git repos from Azure DevOps Server (on-prem).
It is available for Azure DevOps. I create some every week, in fact.
When working with a git repo cloned from our on-prem Azure DevOps Server, then it’s not available. At least to me and Copilot and ChatGPT both say it’s not available for Azure DevOps Server.
VS doesn’t recognize that the solution is in a repo when working in a worktree. The git ui in side panel becomes completely useless.
I use the “bare” flag for initial checkout.
VS doesn’t support worktrees yet. Vote for it here.