Part 3 - Developing with VS 2019

What's it like developing using Git?

Developing in VS with Git is easy but I wanted to call out a few changes. First, you don't need to manually add items to your repo. Your repo will have a .gitingore file that says what can be committed - and what can't. If your .gitIgnore file doesn't specifically ignore it, it will automatically be added. Also, your project folder will need to be in the package directory more than likely (or somewhere under source control in the same repo as your code). If you're using the more than 1 package approach, it can be shared if you like. Additionally, there is no source control explorer. You can compare your changes against the branch you're in but that's it. However, you don't really need source control explorer as a developer. If you're coding, you can do your day to day tasks, commit then create a pull request, or PR, to signal you're done with your work. You can also use the command line for Git if you'd like. it's not required but some people feel more comfortable using the command line. Other than that, it's pretty much the same. I'll demonstrate this below connected to We're going to use a new feature request to walk through this. We will connected to the branch for the task, do our work, commit it, create a pull request then accept that pull request into the main branch. Since we're using GitHub, some specifics may differ from Azure DevOps but the major themes remain the same. With GitHub I can link to every action I take so you can review it if you'd like.

The Experience

We're going to start with a feature that has already been vetted, a branch has been created for me and I just need to do the work. This is to represent what a junior develop would be doing just to illustrate how easy it is. We'll be using GitHub so everything i'm doing after the fact can be reviewed externally. 

I will be starting with branch

I will be using task

First, i'm going to open the task, see which branch i'm suppose to use then switch to that branch in VS. To do this, open Team explorer, select the repo, click on Sync then click fetch. This will get all of the latest branch definitions. Next, go to branch, expand "remotes/origin" then select the branch for the work item. 

Next, i'm going to create a VS Solution and project in the Projects folder for this repo, do the work, then test it. When i'm done, I have this:

With the work complete (and tested) I can now commit. To do that, I would go to Team Explorer then click on Changes. This is what I see:

Notice the branch I am connected to. Other than that, this looks sort of similar to a TFVC commit prompt. Because of Git works with the .gitignore file, all of our additions, changes and deletions are automatically detected and staged. Also, commit comments are required. Next, just click Commit All and then Sync and Sync (again). We're not quite yet done. I've done all the work, tested and committed it but there is one final step: I have to signal that I've completed the work. I do that will a pull request or PR. To do this I click on "Pull Requests" from Team Explorer. Next, click on "Create a pull request". You'll see this:

Notice that we're creating a PR from our working branch "1-add-event-for-vendor-status-change" to merge it into main. Add a description then click "Create Pull Request" and as a developer, you're done (unless the PR is rejected but we'll talk about that later).

The Pull Request can be reviewed at Once reviewed and approved the code and related PR will automagically merge into "main" unless a merge conflict occurred. Additional, some build and test automation could occur as part of the PR. We'll talk more about that in the next chapter.

As a call out, don't use business events for CUD operations. Use Data Events instead.

Blog Main Tag: