In this part of the series, I will have a look at branches and pull requests. These two terms are essential to get familiar with since they are needed when working in teams on the code you are developing.
I want to start with branches and what they are. The way I understand branches is that each time I need to work on an item on my boards, I want to create a new branch matching that board item. When my code is complete and tested OK in the new branch, I will merge it into the master branch (or development branch).
Let’s see how that works in the guide below.
First, I will create a new branch. I usually create the branch from my work items, which is under boards. So I click on “Boards”, which will show the list of my work items, and I will click on the work item I want to use for the branch.
I will assign the work item to the person who will be working on it, I have chosen myself and changed the state to “Doing” instead of “To-do”.
On the top right, I click on the “…” and select “New branch”.
I will provide a name for the new branch, remember that it can’t contain special characters or spaces. It is possible to choose the base for the new branch. I will select “master”, but later on, this maybe something else. As you can see below, the work item is also listed, and you can add more if you want to, I usually have a 1:1 between branch and work item. I will click on “Create branch” to proceed.
Now the branch is created, and as shown below, I can now see which branch is in use. It is possible to change the branch from the dropdown if needed.
Below you can see that I have created two branches to show that I can have multiple branches while working on all of them. One thing to remember is to base the branch on the “master branch” you will merge into when code is complete.
Now that I have my new branch, I want to add some code, I will be doing this from VS Code and to get the branches down. I will need to do a “Pull” from the repo. I do this by clicking on the “…” icon under source control, as shown below. I use “Pull (Rebase)” to get all my local files updates with the files from the repo.
Now that my local repo is updated, I can click in the lower-left corner where it currently says “master”. When I click on that, a dropdown will appear in the top center, and it shows the branches that I can now work with. I will choose “ARMTemplateforVNet” in this case.
I will now add a folder called “VNET”, and under this folder, create a file called “vnet.json”, which will be my ARM template for the virtual network.
Once I have my code working the way I want to, I will commit like shown in the previous part of this series and push that to my Azure DevOps repo. As you can see below, the code in the repo is updated.
To view the files, I can simply click the name of the branch, and it will show me something like the screenshot below. You can see my branch name and the new folder and file I just added.
If I change to the other branch I created, you will see that the new folder and file is not there. I only show you this to see that the two branches only share the files from the branch they are based on. If you make changes to the “master branch” and want to push that into the working branch, there is a way to do this, but I will not cover that right now.
The last section of this part of the series will be on merging the code changes into the “master branch”. Remember that it does not need to be the branch called master, but it should be the one used as the base.
To merge code, I will click on “Pull requests” on the left menu, and after that, I will click on “New pull request” in the right pane.
When creating the pull request, I make sure that the correct working branch is selected and that I have the right destination branch to merge. The picture below illustrates the correct settings. The title will default to the last commit made, and this is fine by me. I click on “Create” to start the merge process.
Now the pull request is started, and it will need to be approved. Since I am working alone on this project, I will click on “Approve”, and after that, I will click on “Complete”. When working in a team, it will usually be someone else approving your pull request to ensure that merges are as safe as possible.
To complete the pull request, you can select the merge type. I always use the “Merge (no fast forward) for the work I do.
When the merge is complete, you will be able to see the flow for the merge. You can also see the “Completed” sigh in the top left, and the option to revert the merge by clicking on “Revert”. Revert can be very useful if you find an error in your code after it went into production, and you have to go back because moving forward to fixing the error will take to long. I will not show the revert process in this part.
Finally, I now have my code merge into the master I have selected, and my code is now in production. If I click on the “Commits”, I can view the flow for my code and which merges has been made in the process of getting to where I am now.
I will conclude this part of the series, and I know there are a lot of pictures and explanations in this part, but I hope it makes sense the way I am using Azure DevOps and source control for my code.
If you have any input on better ways of doing this, please do reach out since I am always willing to learn new and better ways to do stuff.
In the next part, I will be starting on my pipelines, so stay tuned for that one.
/Martin
Comments