Azure DevOps for the Ops consultant – Part 3

In this part of the series, I want to focus on the use of repositories. Repositories are where your code is stored, and in my case, this is often PowerShell code as I will also show in this series.

Also, a part of repositories is the actual source control of your code, there are branches and pull requests. I will show how I am using this, and remember that I am an Ops consultant, so maybe developers are doing this very differently, but this seems to work for me at least.

Let’s dig into it.

The first thing I want to do is to create the first repository where I can store my code. On the left menu click on “Repos”


This will get you to a page like below where you have multiple options for creating the new repo. Usually, I start by cloning my repo into VS Code which can be done by clicking the button for that. There is also an option for cloning the repo from the command line by copying the code there and paste it into a command line that supports GIT. In this guide I will click on the last option which is “Initialize”, this will create a repo with a file in.

Now that the repo is initialized I want to clone it to my machine using VS Code. This is done by simply clicking on “Clone” in the top right corner.

This will bring up the cloning options where the easiest is to click on “Clone in VS Code” which I will do this time.

I click on “Open” to open VS Code


VS Code will ask your permission to open the URI, I click on “Open” again to proceed.


I select the folder I want to save my files in, in this case it will be under “C:\GIT\VSTenant\”. The repo will create a subfolder in this folder with the repo name, I click “Select Repository Location” to proceed.


When VS Code has initialized the repository it will ask if I want to open the cloned repository, I will click on “Open” to proceed.

<a href="images/Repository8.png">Repository8</a>

Now the repository is opened in VS Code and I can start adding my code. Notice that the “” file is synced down, this is the file that was created automatically when I initialized the repo inside Azure DevOps.


I click on the “” file to open it on the rights side editing pane. As you can see below I have edited the file and put in some information about what I am going to do in this project.


I go to “File” and click on “Save” or simply press Ctrl+S.


When the file is saved a blue icon with a 1 inside appears on the left side of the screen. This indicated that I have one change to my files that has not been committed to source control, so I will do that. I click on the icon.


As you can see I have made changes to the “” file, so I need to click on the “+” sign on the right of the file name.


As you can see below the change has now been staged, so the next thing I need to do is provide a comment that describes your commit. I will write “First commit to master” and then click on the checkmark as shown below.


The change is now committed, but I still need to push it out to the DevOps repo. This is done by clicking on the “…” besides the checkmark, and select “Push”.


Now the change has been pushed to the DevOps repo, and I can now view it in the portal. The picture below shows what it looks like inside the portal.


The last thing in this part of the series is having a look at the commits history. I can do this by clicking on “Commits” on the left menu under “Repos”. Now I can see on the right pane that I have the “Added” file first and then I have the commit I just made from VS Code called “First commit to master”.


I have now covered quite a bit on the use of repos inside of Azure DevOps. I now have my files and code under source control, and I know how to commit and push code from VS Code. In the next part of this series, I will have a look at branches and pull requests and how I use them when I write code.

Thank you for following along