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.
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.
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.
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.
To create a new repository:
- Click File –> New –> Repository…
- The Team Explorer opens on the right
- Pick the folder that you want to create the repository in
This is equivalent to running
git init from the command line.
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?
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.
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.
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.
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 addon 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
.gitignorefiles based on built in templates.
.gitignore file was sourced from the GitHub gitignore repository.
+ 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.
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”.
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.
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.
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.
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.
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.
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.
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
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:
- bugfix/ prefix indicates that work committed to the branch represents changes for a bug fix. Example:
- hotfix/ prefix indicates the branch will have an escalated release path because of critical fixes included on it. Example: