Getting started with Azure DevOps & Source Control

Summary

Azure DevOps has a very robust source control system. It’s really easy to adopt and the learning curve isn’t too steep either. Below I outline the steps needed to get started with a Azure DevOps and Git source control.

The basic workflow for managing your source code using Git is as follows:

1. Create a new project.
2. Initialize source control.
3. Setup identification.
4. Set the branch policies.
5. Push a readme file to master
6. Create a user or feature branch.
7. Update the readme file.
8. Create a pull request.
9. Approve the pull request.
10. Manage changes using 'git pull'.

Before we begin

Some important points to remember:

1. Where I specify URLs for connections to repositories, replace these URLs with your project specific URLs.
2. Where you see specific user details (syed.hussain) replace these with your own credentials.
3. You must have elevated privileges in order to set branch policies and to create branches.

1. Create a new project

Login to your organisation workspace: https://azure.microsoft.com/en-gb/services/devops/

Once logged in create a new project to host your source code. I’ve named my project Google Postcode Lookup.

2. Initialize source control

Once a project has been created you’ll need to initialize the repository. Azure DevOps provides a few options to set this up:

1. Clone the repository to your local computer.
2. Push an existing repository from the command line.
3. Import a repository.
4. Initialize with a README or gitignore.

We’re going to clone this repository to our computer, so select the first option clone to your computer, however before you do this ensure you generate Git credentials. We’re going to use these credentials to later authenticate when we need to work from the terminal, command prompt or Microsoft Visual Studio Code.

Once credentials have been set, on your local computer type the following into the command prompt or terminal:

mkdir 'Google Postcode Lookup'

cd 'Google Postcode Lookup'

Note: Replace the URL with your HTTP URL.

git clone https://eax360.visualstudio.com/Google%20Postcode%20Lookup/_git/Google%20Postcode%20Lookup

You will be prompted for the credentials you created earlier. Once these have been entered, the following or similar output should be displayed:

Username for 'https://eax360.visualstudio.com': SyedHussain
Password for 'https://SyedHussain@eax360.visualstudio.com': 
warning: You appear to have cloned an empty repository.
Syeds-Macintosh:Google Postcode Lookup syed263$ 

Note: If you receive: 'warning: You appear to have cloned an empty repository.' this is fine, the repository should be empty.

3. Setup identification

Before you can make any commits, you will need to setup some identification. This is important so that commits can be traced back to you.

git config --global user.name "Syed Hussain"
git config --global user.email syed@eax360.com

4. Setup branch policies

In the Project Settings, under Repositories set the branch Access Control settings. For guidance I have set this with the following options for the Contributor role:

5. Push a readme file to master

When you first setup a repository, the master branch is empty. It’s common practice to commit to a Git repository with something like a readme.md file. We’ll create a readme.md file and commit the untracked file back to the master branch. Create a new file called readme.md and save in the root folder. Once this is complete, issue the following command to add the untracked file into your local repository.

git add .

git commit -a -m "adding readme.md file"

git push

Once this is complete, you should see the following or similar output:

Counting objects: 3, done.
Writing objects: 100% (3/3), 237 bytes | 237.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Analyzing objects... (3/3) (6 ms)
remote: Storing packfile... done (137 ms)
remote: Storing index... done (54 ms)
To https://eax360.visualstudio.com/Google%20Postcode%20Lookup/_git/Google%20Postcode%20Lookup
 * [new branch]      master -> master
Syeds-Macintosh:Google%20Postcode%20Lookup syed263$ 

The file should now be uploaded and visible in the master branch

6. Create a user or feature branch

From the command prompt or terminal, issue the following commands to create a new user branch.

git branch users/syedhussain

git checkout users/syedhussain

git push --set-upstream origin users/syedhussain

You may notice that the branch you just created is now listed under the branches menu.

7. Update the readme.md file

To demonstrate branching, we’re going to modify the readme.md file. Add the following line to the readme.md file:

//File edited by syed hussain as a feature.
//Description: demonstration of branching features of git and Azure DevOps.

Now commit the changes back to the remote branch.

git commit -a -m "updated readme.md file"

git push

If you review the push to your branch, you’ll notice that this last commit is now available for review.

At this point, we are now ready to have our changes reviewed and merged into the master branch.

8. Create a Pull request

A ‘pull request‘ is when you are asking for your changed to be pulled into the master branch. You submit a pull request when you are satisfied that you have fixed a bug or delivered a feature. A pull request is followed with a review with the project or technical lead. This is often the person that is responsible for maintaining the master branch.

To create a new pull request click on the ‘Create a pull request‘ link.

Complete the form with appropriate detail.

Once you have completed the pull request, it’s time to submit the pull request.

9. Approve the Pull request

The process for approving a pull request is very simple. In its basic form, you compare the master source file with the proposed changes. If you are happy with the changes, you can mark the pull request as approved. Marking a pull request as approved does not merge the changes with the master source files, however it is a method of notifying other reviewers that you have approved the changes and you are happy to proceed to the next step – the action that will merge the changes into the master branch.

The action step is very simple. You have the following options: Complete, Mark as draft and abandon. In our setting we will action the pull request as complete.

Note: On completion of a pull request, the branch can be deleted in some workflows if the feature has been delivered.

Clicking on the Complete merge button, completes the pull request.

Inspecting the readme.md file on the master branch now shows the updated changes made.

10. Manage changes using ‘git pull’

There are often times when you’ll be working quite happily from your local repository but will need to update your local repository with code changes committed by a team member in the remote branch.

To update your local repository with the new changes in the remote branch, you issue two commands:

1. fetch – retrieve the latest changes.
2. merge – combine the code changes with the local repository code.

To fetch the changes only, issue the following command:

git fetch

To merge the changes into your local repository, issue the following command:

git merge

To combine both a fetch and a merge into a single command, use git pull.

git pull

Some important information to understand about fetching and merging changes. The git fetch, git merge and git pull, only pulls changes from the remote working branch. So, if you are working locally in the users/syedhussain branch, don’t expect updates in the master branch to automatically cascade into your repository.

For example, in my master branch I have three files:

In my users/syedhussain I have only one file:

When I issue the command ‘git pull‘ from the branch users/syedhussain I am told that the branch is up-to-date.

This behaviour is actually correct. If you and your team is working on a feature such as a password reset functionality, you don’t want to pull in changes that implement other features such as an address book or contact management. You just want to focus on delivering your feature. In fact, some teams prefer to have a branch naming convention based on features instead of names:

features/portal/login
features/portal/passwordreset
features/portal/singlesignon

Branch design can be a complicated subject. It is always best to start with a simple model and tweak as necessary.

Final words

Azure DevOps is a great platform for managing the application lifecycle of a project. This post was a gentle introduction to Azure DevOps and source control. Using the foundation lessons learnt in this post you can now move on to more advanced topics.

For more information visit the Microsoft Azure DevOps Git reference website: https://docs.microsoft.com/en-us/azure/devops/repos/git/?view=azure-devops