This article explains the concept of branches in Git and Azure DevOps repositories, why branches are needed, how they work behind the scenes, how to create and switch branches, and the process of merging branches. It clarifies that branches are pointers to commits, not copies of files, and highlights best practices for managing code changes safely.
Welcome to this detailed guide on branches in Git and Azure DevOps repositories. Branching is a fundamental concept in version control systems like Git, and understanding it is crucial for effective code management, especially when working in teams or managing multiple features and fixes simultaneously.
In this article, we will cover:
To understand branches, let's first look at how Git works when you work on a repository.
When you create a new repository and add code, you create commits. Each commit contains:
Git tracks these commits using pointers. Each pointer keeps a snapshot of the repository's state at that commit and stores this information in Git's database.
When you create a new commit, the pointer that was previously pointing to the last commit moves to the new commit. This pointer effectively tracks the latest commit in a sequence.
If we give a meaningful name to this pointer, it becomes a branch. In other words, a branch is simply a named pointer that tracks a series of commits.
When you create a new repository, Git automatically creates a default branch named master. If you haven't created any other branches, all your commits are made on the master branch.
Imagine you have a working codebase on the master branch, and you receive a new requirement to create a proof of concept (POC) based on the existing code.
You could make changes directly on the master branch, but this approach has risks:
master can disrupt the stable version.To avoid these issues, you create a new branch from master to work on the POC separately. This way, the master branch remains stable and unbroken.
Creating a new branch does not duplicate your files or increase the repository size. Instead, it creates a new pointer to a specific commit.
For example, if your repository size is 200MB on the master branch, creating a new branch will not double the size. Both branches point to the same files until changes are made.
This efficient management is possible because Git uses reference management, where pointers reference the actual files without duplicating them.
When you create a new branch, you give it a meaningful name that reflects its purpose, such as POC for a proof of concept.
Now, you have two branches:
master (the stable branch)POC (the new branch for experimental changes)To work on a particular branch, you need to switch to it. For example, if you are currently on master and want to work on POC, you switch to the POC branch.
Once switched, any commits you make will be recorded on the POC branch only. The master branch remains unchanged and does not include the new commits until you merge.
You can create a new branch from any existing commit, not just from the latest commit on a branch. This flexibility allows you to manage your codebase effectively.
For example, you can create a new branch from the POC branch if you want to work on a different feature or fix without affecting the POC branch.
Once your work on a branch like POC is complete and tested, you may want to integrate those changes back into the master branch.
This process is called merging. Merging combines the commits from one branch into another, updating the target branch with the new changes.
After merging, the master branch will include all the commits made in the POC branch, effectively updating the stable codebase.
There are different merging strategies, including pull requests and direct merges, which help manage code integration safely and collaboratively.
master, created automatically with a new repository.Understanding and using branches effectively is essential for managing code changes, collaborating with teams, and maintaining a stable and organized codebase.
In the next tutorial, we will learn how to create new branches directly from the Azure DevOps server repository.
Thank you for reading, and happy coding!
