3/22/22, 5:21 PM Version Control - Overview

Version Control
Last updated by | Jhonatan Reyes | Feb 23, 2022 at 10:55 AM GMT-5

Contents
• Introduction
• Scope
• Technologies used
• Branching model concept
• Use case using Azure Repos with Azure Boards
• How to create a branch
• Pull request creation
• Git command line
• Clone the repository from Azure Repos:
• Update a local repository:
• Push changes to the repository:
• Cloning specific branch:
• Pull request approval
• General considerations
• Approvers list
• Versioning control

Introduction
This document is intended to cover all the required explanations to follow a branching model for the ELT
development process.

Branching explanation.

Scope
Applies to ELT development team.

Technologies used
This branching approach was implemented on top of the following technological tools:

Git: Software version control.

Azure Repos: Web-based version control based on Git.

Azure Boards: Software designed to help with the tasks in the development process.

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 1/15

3/22/22, 5:21 PM Version Control - Overview

Azure Pipelines: Automation service to build and tests code projects to make them available to others in
different environments.

All technologies are in the Azure DevOps portal. The scope of this document is to list these tools for reference,
further investigation is required by the reader.

Branching model concept

A branching model can be defined as a strategy in how to manage all the related work in regard to version
control, allowing the developer’s team to move fast and have better visibility on the work that is being done. To
reduce the pain (and effort) for the team, the branching strategy is aimed to:

Optimize productivity.
Enable parallel development.
Allow for a set of planned, structured releases.
Provide a clear promotion path for software changes through production.
Evolve to accommodate changes that are delivered, daily, weekly, or whenever it is needed.
Support multiple versions of released software and patches.

The idea of using this approach is to efficiently manage code changes when requested by the client and make
an organized path from the start of the development process until the end, which is the deployment of the
development itself.

The way the branching model was implemented is oriented to Feature Branching Strategy (Task branching). This
type of work allows the developers to create a branch for a specific feature/issue, which is referred to as service
desk tickets. This branch-per-issue workflow allows developers to work separately

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 2/15

3/22/22, 5:21 PM Version Control - Overview

The previous image shows us a common approach for the task branch strategy. Each “feature” or “Task” branch
will be created by the developer using the issue/ticket number and all the changes in the code that may occur
will be committed at first on this branch, and later a Pull Request (PR) will be created to merge all changes to
the Development or Master branch.

Use case using Azure Repos with Azure Boards

After the Task or bug creation, we must proceed and create a new branch in our versioning tool Azure Repos

Through the Azure DevOps Web interface, we can perform all the necessary steps to create the branch and Pull
Request (PR) for the development in the course. For this, use your assigned Team international account to
access the repository:

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 3/15

3/22/22, 5:21 PM Version Control - Overview

To work on a specific repository, select the project that you are going to make an adjustment to, as soon as you
enter it, you will see the following options:

From the left side, you can see all the available options for the project, the most relevant options related to the
branch creation are as follows:

Source: This is the main page of the repository, here you can check all the source code related to the
project.

Commits: Here you can check all the recent commits that were done to the project filtered by branch.

Branches: Here we can see all the branches created by the team, in here we can browse between them and
create new branch.

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 4/15

3/22/22, 5:21 PM Version Control - Overview

Pull requests: From this page, we can manage all the open PR (Pull requests) also we can create a new one
after our development is ready for promotion

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 5/15

3/22/22, 5:21 PM Version Control - Overview

In general, this is a quick overview of using Azure Repos and the required options to understand how this
works.

How to create a branch

While working on a feature or bug fixing, a branch must be created with the User Story ID that is being worked
on with the following structure:

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 6/15

3/22/22, 5:21 PM Version Control - Overview

The branch name must be the User Story ID from Azure boards. Keep in mind that the branch name or User
Story ID may differ depending on the project, however, each field from that form has a purpose:

Work Items to link: This one is important, depending on the task please select the appropriate value
according to the User story, if it is a task or bug.

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 7/15

3/22/22, 5:21 PM Version Control - Overview

Based on: Indicates from which branch the developer will copy the data into the new branch.

Branch name: The developer indicates the name of the new branch using the User Story ID number only.

The creation of the branch can be accomplished in two ways:

**- Azure DevOps Web interface.

Command-line using Git.**

After branch creation, you can now use this new branch to add or modify the source files as requested in the
Task, all commits must be done inside this branch every time.

Pull request creation

As mentioned in the previous topics, all developments after the branch creation and before moving all objects
to production, a Pull Request (PR) must be created and approved by our peers before anything can reach
production.

To do this, a PR is created using Azure Repos as follows:

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 8/15

3/22/22, 5:21 PM Version Control - Overview

Please fill out the form provided by Azure Repos with enough information about the changes that are going to
be merged to the Master branch. The title and description fields must be filled by the developer without
exception. If the PR doesn’t comply with a proper description It will be rejected.

During the PR creation, before merging the changes to production, we need to add the reviewers of the
change, and those are the ones who finally approve the PR and all the changes are committed/merged to the
Master branch. The approvers from the team will be listed in this document in the section “Pull request
approval”.
https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 9/15
3/22/22, 5:21 PM Version Control - Overview

After the PR creation, both reviewers must approve the PR to merge the changes to the Master branch before
promoting everything to production. This is a mandatory step.

On this page we can manage everything related to this process, here we can see when the reviewers have
approved or commented on the development. All the communication threads regarding the technical part of
this process must be done through the comment section:

In the previous image, we can see that all comments/communication in regard to this PR happens here. In this
place, both developer and reviewers manage all communications. Documents can be attached here if needed.

The outcome of any Pull Request can be one of the two:

Approved: The changes are merged to the Master branch.

Rejected: Developer must validate the reviewer’s comments and make the necessary changes.

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 10/15

3/22/22, 5:21 PM Version Control - Overview

Git command line

Git is a free and open-source version control system designed for small software projects to big ones. Azure
Repos is based on Git, as such, we can use all the Git client features to manage our repository through the
command line.

Git can be downloaded at this link:

Git - Downloads 

The official page contains enough information to get started using this tool, all the commands and usage of this
tool can be learned from here:

Git - Book  or Git - Reference 

To give a better reference about how Git can be used for branching, please check these documents, which
contain some valid examples of how this approach works:

Git - Branches in a Nutshell  Git - Basic Branching and Merging 

NOTE: Remember to complement all this information use this link Git - Book  or this one Git - Referenc  here
you can find all the topics and documentation related to Git.

Use case using Git

This process is similar to the one described before using the Azure Repos interface, but with the difference that
it is done through commands in the Git command line.

To use Git, you need to have installed Git on your computer as described in the next numeral.

In the Start menu, you must open your favorite interface to use Git, in this case, we will use Git Bash, but you
can use Git CMD which works from the CMD interface, or Git GUI which uses a graphic interface.

First, you must ensure that you have the most recent version of the repository in your local machine. To do this
you can clone the repository from bitbucket or if you already have a local copy of the repository which you
used before you must ensure it is updated. These two processes are described below:

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 11/15

3/22/22, 5:21 PM Version Control - Overview

Clone the repository from Azure Repos:

you can go to Azure Repos, choose the repository, click on clone and click the Copy button, this will generate
the URL Address and you must complement the Git Clone command such as:
git clone https://TEAM-DOGS@dev.azure.com/TEAM-DOGS/Data%20Research%20and%20Development/_git/elt_mdm

You must paste and execute this command on Git, this will copy the content of the folder from Azure Repos to
your local machine. You can enter this folder with CD command. By doing this you will be working by default on
the master branch which means that this command makes a check out to master by default.

Update a local repository:

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 12/15

3/22/22, 5:21 PM Version Control - Overview

you must be working at the master branch, so if you need to change the branch you must run:

git checkout main

Execute
git fetch origin

to find all the changes that the master branch had and execute
git reset --hard origin/main

to make sure that you have the most updated version.

After ensuring that you have the most recent version of the branch, you should create a branch by executing

git checkout -b <name>

This command creates a new local branch with a given name whose characteristics have been described before
and besides that, it makes a check out to this branch.

Push changes to the repository:

To make a copy on Azure Repos of this new branch you must execute
git push -u origin <branch name>

After that, you will not be able to see this branch on Azure Repos because it has the same code as the main
branch, but you will be able to start working locally on this branch from your preferred IDE.

Cloning specific branch:

To clone and specific branch locally, you must run:

git clone <url> --branch <branch> --single-branch

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 13/15

3/22/22, 5:21 PM Version Control - Overview

Pull request approval

General considerations
Pull Request go through an approval process as mentioned before in which other team members validates and
approves the changes uploaded by the developer. The Pull Request approvers have the following
considerations while evaluating the Pull Request if any of the following does not comply the PR can be rejected
until all necessary adjustments are made:

Unit testing evidence: The developer must attach to the ticket evidence of the testing made.

Execution logs: The developer must attach evidence of successful execution in the development
environment.

SQL scripts: If the development requires modifying or the creation of production database objects, the
script must be provided.

Proper code writing: Queries or code developed must be written in accordance with good practices.

Job development good practices: Jobs developed must comply with a minimum of good practices (no
hardcoded queries, connections, email notifications, and such).

Valid PR creation: Complies with the proper name and documentation.

Documentation: Validates if the documentation was created or adjusted.

All line of communications in regard to this takes place inside Azure Repos as mentioned in the Pull request
creation section.

Approvers list
The following users are the ones authorized to check and approve the Pull Request:

Name Position Email

Luisa Zuluga Data Architect Luisa.Zuluaga@teaminternational.com

Katerine Meneses Data Lead katerine.meneses@teaminternational.com

Accept pull request: You can go to Azure Repos, choose the pull request and you can see the changes to be
merged, conflict, documentation, approve or reject the PR, among others:

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 14/15

3/22/22, 5:21 PM Version Control - Overview

Versioning control
During the PR process and merging all the changes to the Master branch, we may encounter a situation in
which our changes have conflicts with another development. In such scenarios, we may involve all people
affected by this.

This means that we must reach the Team Leads, developers of the current branch, and the developers or team
members involved in the conflict. In these cases, we must negotiate with the other team or developer on how to
proceed also in this case with the rule of first-come, first-serve.

Versioning conflicts must be addressed as a team to avoid broking the development from another ticket or
team.

https://dev.azure.com/TEAM-DOGS/Data Research and Development/_wiki/wikis/Data-Research-and-Development.wiki/678/Version-Control 15/15