This is your brain. This is your brain on computers.

Using Git with Visual Studio 2019: The Ultimate Guide

We’ve written extensively in previous articles about the non-negotiable importance of learning source control to become a software engineer and the most popular tool to accomplish it: Git. Git’s command line has, for lack of a better way of describing it, evolved into somewhat of a conflicting journey. If you’re looking for a better experience to manage your Git repositories, this guide introduces you to using Git with Visual Studio 2019.

Many developers prefer having the ability to manage repositories inline with the development environment to reduce having to context switch between applications. The downside to this is that you lose the flexibility and customization of the command line. We suggest you start with our extensive guide to Git and follow that up with this guide so that you know how things are working under the hood.

And hey, if things start going haywire, you’ll know how to use the backup method!

Install Git & Learn Git

Git works natively on Windows, Mac, and Linux. When using Windows, you’ll most likely be using the tools included in the Git for Windows initiative (Git BASH, Git GUI, and Git Shell Integration). Even though Git is completely cross platform, Visual Studio 2019 only works on Windows.

To get started, go to the download Git page or directly to the download link for Windows since you’re stuck on Windows with Visual Studio.

Don’t know how to use Git? Take a look at our Getting Started with Git guide so that you’re set up for success and ready to contribute to projects with confidence.

Install Visual Studio 2019

Microsoft sometimes has weird ways of naming their products (Azure DevOps, we’re looking at you). There was a period of time when everything was named with the Visual Studio prefix. That said, don’t confuse Visual Studio 2019 with Visual Studio Code. This guide only uses Visual Studio 2019.

Let’s get started.

Download Visual Studio 2019 Community Edition (free). Read our pricing guide for more detailed comparisons between editions. We suggest the Community Edition because you won’t need any of the features offered by the pricier (and they can be pricey) tiers.

Browser window showing where to click to download Visual Studio 2019 community edition.
Visual Studio 2019 Community Edition (not to be confused with Visual Studio Code).

Microsoft recently overhauled the installation process. It’s much, much better than it used to be, so let’s all take a moment of silence to appreciate that.

Anyway, you’re not going to need the thousands of options that are available to you during the initial installation process. This guide only uses the “.NET Core cross-platform development” group and its required dependencies. Feel free to opt in to anything else you think looks interesting but be aware that you will have to download everything. Some of these options can increase the download size by 5+ GB.

Visual Studio installer UI showing to install only .NET Core tooling.
Select what you want but beware the download sizes.

Let the installer do its thing. Sit back, relax, and wait for the magic. While it’s downloading, you can check out our article on 5 Essential Visual Studio Extensions. Used properly, extensions have the potential to boost your productivity and development efficiency.

Create New Git Repository

You’ve got Visual Studio, and you’re ready to roll. If you want to know how the Visual Studio Git UI is interacting with Git under the hood, read our introduction to Git to learn the basics of the command line.

Visual Studio tries to be helpful on launch, but sometimes jumps the gun. In this case, we don’t want to create any projects to start. Instead, we want to create a new repository, but that’s hidden behind the tiny link in the bottom right: “Continue without code.” Click it.

Visual Studio UI showing where to click to skip project creation and create a Git repo first.
Skip project creation since we want a repository first.

To create a new repository:

  1. Click File –> New –> Repository…
  2. The Team Explorer opens on the right
  3. Pick the folder that you want to create the repository in

This is equivalent to running git init from the command line.

Visual Studio UI showing where to create a new Git repository.
Create and confirm where the repository will live.

Create Project In New Git Repository

The repository is ready to go, but it’s empty. Confirm that the repository now shows in the “Local Git Repositories” section of the Team Explorer.

Initiate the Project Creation Wizard by clicking File –> New –> Project. Yes, there are keyboard shortcuts to do this, but they’re not very convenient. You can remap them, but really how often are you going to be creating new projects to justify a handy shortcut?

Visual Studio UI showing where to create a new project.
Confirm successful repository creation. Initiate new project wizard.

There are definitely a lot of project templates to sift through. If you selected more installation options in the first steps of this guide, you’ll be absolutely swimming in them.

Search for “console” to filter down to just console applications. Select “C# Console App (.NET Core)” to create a new console application based on whatever version of .NET Core SDK was installed with Visual Studio 2019. Note that there are templates for other languages (VB and F#) that aren’t relevant to this tutorial.

Click Next.

Visual Studio UI showing where to create a new .NET Core console application.
Create a new .NET Core Console Application.

Enter your project name, select the folder location in which you initialized the Git repository from previous steps. If you get this wrong, you won’t be able to follow along with the rest of the guide.

Click create, and you’re good to go. Your solution, project file, and template classes will be created and placed in your repository folders.

Visual Studio UI showing how to make a new project with caveats.

Commit New Project to Git

Visual Studio has a “Team Explorer” docked sidebar (you can drag it to move it around) which enables you to manage your local Git repository and attached remotes.

Change the Team Explorer section drop down to “Changes” so that you can view changes on your active branch (which is the master branch at the moment).

Even though your project has been added to your local repository folder, you haven’t yet committed those changes. Files that Git recognizes as new are not tracked by default and require you to explicitly add the files to be tracked. If you don’t see any changes listed here, go back to the project creation step and make sure that you created the project in the same folder as the Git repository.

Visual Studio UI showing where to see Git repository code changes.
Use Team Explorer to manage your local and remote repository contributions.

The Changes window in the Team Explorer tab breaks down changes in two ways: “Changes” and “Staged Changes”.

  • Changes is a list of pending file changes that you haven’t acted on. That is, you haven’t run git add on those files to stage them for a commit.
  • Staged Changes is a list of files that have been added to Git’s staged tracking list to be committed. In this step, Visual Studio’s repository creation wizard has automatically staged .gitattributes and .gitignore files based on built in templates.

Specifically, the .gitignore file was sourced from the GitHub gitignore repository.

Visual Studio UI showing where to see staged and pending Git changes.
Staged Changes and “Regular” Changes are split in the Visual Studio UI.

Click the + to stage all changes. In this case, staging everything is fine, but in the real world, you might want to pick and choose exactly which changes to stage. It’s common for developers to make local changes specifically for debugging or testing purposes without the intention of committing those to the repository.

Do yourself and your team a favor by always double checking your changes prior to staging and definitely prior to commitment.

Visual Studuio UI showing how to stage changes.
Confirm your changes prior to staging.

The Team Explorer UI will update with all changes in the Staged Changes section. Confirm that these are as you expect prior to commitment.

If anything looks wrong at this step, you can Unstage by right clicking the file and selecting “Unstage”.

Visual Studio UI showing how to confirm changes are ready to be committed.
Double check staged changes prior to commitment.

Good commits have good commit messages. Good commit messages aren’t too short and nor too long. That’s vague, but the point is that you should be descriptive enough for those who will come after you but without requiring the reader to struggle to the end.

You have three options here:

  • Commit Staged to commit staged changes to the local repository
  • Commit Staged and Push to commit staged changes to the local repository and push to a remote repository (like GitHub or Bitbucket)
  • Commit Staged and Sync to commit staged changes to the local repository, pull changes from a remote repository, and then push your changes to that remote repository

We only care about the first one for this guide because we have no remote repositories setup.

Visual Studio UI showing how to commit to local Git repository.
Write a good commit message and commit to the local repository.

At this point the project is committed to Git and enshrined in the history forever. Let’s work on incremental changes now.

Commit a Change to Git

Any time you add or change a file to the tracked repository, the Visual Studio Team Explorer will automatically detect and display the changes in the Changes tab.

Add a line to the Program.cs file and watch as the change displays automatically.

Visual Studio UI showing how to make a change and have Git recognize it.
Changes are automatically detected and displayed.

Before you commit stage and commit changes, always check to make sure the changes are what you expected. Long development sessions can leave behind unwanted comments and code that you intended to remove prior to commitment.

Right click the file or folder that changed and click “Compare with Unmodified…” to see what changes are pending to be staged or committed.

Use the comparison tool to confirm your changes.

The previously chosen option will launch the Visual Studio Diff Viewer, which displays changes between the HEAD (left, unmodified state of your branch) and the current state (right, pending changes that haven’t yet been committed).

Red lines on the left indicate the previous state. Green lines on the right indicate the current state.

Always confirm that these changes are exactly as you expect.

Double check your changes prior to commitment.

If everything is as expected, just like before, click the + to stage the changes. Enter the commit message (a good one). Click “Commit Staged” to commit to the local repository.

Visual Studio UI showing how to stage and commit a change to local Git repository.
Stage, message, commit is a common workflow.

We encourage all developers to commit early and commit often. Reduce your risk and keep your coworkers sane by maintaining small and frequent changes.

Create and Commit to a Local Branch

As we previously wrote about in 5 Essential Things Every Programmer Should Know, branching is critical to your success, your team’s success, and ultimately your project’s success.

Without the ability to create independent branches of code, team members would be conflicting with each other every time a developer made a commit. Since we also advocate for committing early and committing often, such conflicts would be an immediate deal breaker.

Change the Team Explorer section drop down to “Branches” so that you can view all branches in the local repository.

Visual Studio UI showing how to switch to Git "branches" view.
View branches using the Branches tab in Team Explorer.

The only branch in a new repository is the default branch known as master. Until now, all changes have been committed against that branch.

Right click the master branch, click “New Local Branch From…” to begin creating a branch based on the current state of master.

Visual Studio UI showing how to create a new local branch.
For new repositories, only master will exist as a branch source.

The new branch UI will display in the Team Explorer. Name the new branch, confirm that you are branching from master, and select to checkout the branch so that you don’t have to do that manually after creation. It’s just an option for convenience.

Branch naming is a hot topic and can invoke a lot of opinions. One common naming convention is found in the Gitflow Workflow.

  • feature/ prefix indicates that work committed to the branch represents changes for a new feature. Example: feature/add-new-questions-to-ui.
  • bugfix/ prefix indicates that work committed to the branch represents changes for a bug fix. Example: bugfix/fix-broken-login.
  • hotfix/ prefix indicates the branch will have an escalated release path because of critical fixes included on it. Example: