What Is Branch in DevOps?
On This Page
Quick Definition
In version control, a branch is like a separate workspace where you can make changes to your code without affecting the main project. Developers use branches to work on new features, fix bugs, or experiment safely. Once the work is complete and tested, the branch can be merged back into the main codebase. This keeps the main code stable and organized.
Commonly Confused With
A fork is a complete copy of a repository (often on a different server, like GitHub) under a different account. Forks are used when you do not have write access to the original repo. In contrast, a branch exists within the same repo and shares its commit history. Forks are common in open-source contributions; branches are used inside a team repo.
Forking a repo on GitHub means you create your own copy of the whole project. Branching means you create a new line of work inside the same project.
A tag is a static pointer to a specific commit, usually used for marking release points (e.g., v1.0). Unlike a branch, a tag does not move forward as new commits are made. Tags are typically read-only and used for historical reference, while branches are moving pointers for ongoing development.
A tag is like a bookmark in a book marking a specific page. A branch is like a bookmark that moves as you read further.
A clone is a local copy of an entire repository, including all branches and commits. Cloning is how you download a repo to your machine. Branches are just pointers inside a repository; you can have many branches in a single clone.
Cloning is like copying an entire book. Branching is like using sticky notes to mark different sections inside that book.
Merge is the operation that combines changes from two branches into one. A branch is just the pointer; merge is the action. You can have a branch without ever merging it, and you can merge branches as part of the workflow.
A branch is the road, and merging is the intersection where two roads meet.
Must Know for Exams
For the AZ-400 exam, the concept of branching is fundamental and appears across multiple objectives, especially in 'Implement source control' (AZ-400 exam objective). Candidates must understand how to create and manage branches in Azure Repos, configure branch policies, and set up branch protection rules. The exam expects you to know the difference between local and remote branches, how to merge and rebase, and when to use each strategy.
Common exam question patterns include scenario-based questions where you are given a team workflow and must choose the correct branching strategy (e.g., GitFlow vs. GitHub Flow). Another frequent topic is troubleshooting merge conflicts: you might be asked to identify the best way to resolve a conflict when merging a feature branch into main. Questions also cover how to use 'git merge --no-ff' vs. 'git rebase', and how these affect the commit history.
the exam tests your knowledge of Azure Repos-specific features like branch policies for required reviewers, automatic reviewers, and status checks (e.g., successful pipeline runs). You may be asked to configure a branch policy that prevents direct pushes and requires a pull request with at least one reviewer. There are also questions about linking branches to work items in Azure Boards to ensure traceability.
In the 'Design and implement a strategy for releasing and managing versions' domain, branches relate to release management. You might need to advise on the correct branching strategy for a release that requires hotfixes. Understanding how to create a release branch from main, apply a hotfix, and then merge back into both main and develop is a specific exam skill. The exam is practical and scenario-driven, so rote memorization of Git commands is less important than knowing the strategic purpose of branches in a DevOps pipeline.
Simple Meaning
Imagine you are working on a group school project with a shared document on a whiteboard. The whiteboard is your main codebase. If you want to draw a new diagram or try a different layout, you would not want to erase everything everyone else has already written. Instead, you take a photo of the whiteboard at that moment, then sketch your ideas on a separate piece of paper. That separate piece of paper is like a branch. You can draw, erase, and perfect your changes without disturbing the whiteboard. Once your idea is polished and approved by the group, you can copy it back onto the whiteboard for everyone to see.
In software development, a branch works exactly like that separate piece of paper. The main code lives on a branch often called 'main' or 'master'. When you need to add a new feature or fix a bug, you create a new branch from the latest version of the main code. You then work on your branch, making commits (saving checkpoints) as you go. Meanwhile, other developers can keep working on the main branch or on their own branches. This isolation prevents conflicts and keeps the project stable.
Branches also enable collaboration. Multiple developers can work on different features at the same time without stepping on each other's toes. When each feature is complete, it gets reviewed and merged back into the main branch. This approach is the foundation of modern DevOps workflows and is a key concept for the AZ-400 exam.
Full Technical Definition
In Git, a branch is a lightweight movable pointer to a commit. The default branch is usually named 'main' (or 'master' in older conventions). When you create a new branch, Git creates a new pointer that initially points to the same commit as the branch you branched from. As you make new commits on the new branch, the pointer advances forward, while the original branch pointer stays where it was. This mechanism allows developers to diverge from the main line of development and continue work independently without affecting the main codebase.
Branches are not separate copies of the entire repository. Instead, Git stores commits as snapshots with parent references, and branches are just named pointers to specific commits. This design makes branch creation very cheap in terms of storage and performance. Internally, Git stores branch references in the .git/refs/heads/ directory, each as a text file containing the SHA-1 hash of the commit it points to. When you switch branches using 'git checkout' or 'git switch', Git updates the working directory and index to match the state of the branch's tip commit.
Git supports several types of branches: local branches (isolated to your local repository), remote-tracking branches (local copies of remote branches, e.g., origin/main), and remote branches (branches stored on the remote server). The 'git branch' command lists local branches, while 'git branch -r' lists remote-tracking branches. Common workflows include feature branching (each feature gets its own branch), release branching (a branch to stabilize a release), and hotfix branching (a branch from a release to fix a critical bug).
In the context of Azure DevOps and the AZ-400 exam, understanding branch policies is critical. Azure Repos allows you to enforce branch policies such as requiring a minimum number of reviewers, successful builds, or linking to work items before a merge is allowed. These policies ensure code quality and compliance. Branch protection rules prevent direct pushes to important branches like main, forcing changes to go through pull requests and automated CI/CD pipelines.
Real-Life Example
Think of a team of chefs preparing a complex meal in a kitchen. The main recipe board on the wall shows the current menu for the evening. That board is the main branch. Suppose one chef wants to experiment with a new sauce for the pasta. Instead of rewriting the main recipe board and risking ruining the dish for tonight's service, the chef takes a picture of the current board and copies the recipe onto a separate notepad. That notepad is a branch.
On the notepad, the chef tries different ingredients, adjusts the cooking time, and takes notes. At the same time, other chefs continue cooking the main dishes using the original recipe board. Their work is not disrupted. Once the chef perfects the new sauce, they present a sample to the head chef. If approved, the new recipe is added to the main board, and everyone starts using it. The notepad (the branch) might be kept for future reference or thrown away.
This analogy maps directly to software development. The recipe board is the main branch of the code repository. The notepad is a feature branch. The chef's experimentation is the development work, and the head chef's approval is the code review process. The moment the new sauce becomes part of the main board is the merge commit. If the chef had made a mistake, the main board would remain unchanged, and only the notepad would be discarded. This isolation is the core value of branches.
Why This Term Matters
Branches are essential for maintaining code quality and enabling parallel development in modern DevOps practices. Without branches, all developers would work directly on the same codebase, leading to constant conflicts, broken builds, and lost work. In a professional IT environment, branches allow teams to implement GitFlow, GitHub Flow, or trunk-based development strategies. For example, a team might use a 'develop' branch for integration, 'feature' branches for individual work, and 'release' branches for final testing.
Branches also support continuous integration and continuous deployment (CI/CD). Azure Pipelines can be configured to trigger builds and deployments automatically when code is pushed to specific branches. For instance, a push to the main branch might trigger a production deployment, while a push to a feature branch might run unit tests only. This automation increases velocity and reduces human error.
In regulated industries, branches combined with branch policies provide audit trails. Every change to the main branch must go through a pull request, be reviewed by at least two senior developers, pass automated tests, and link to a work item. This ensures that no unauthorized or untested code reaches production. For the AZ-400 exam, understanding how to configure branch policies, set up branch protection, and manage pull requests in Azure Repos is a key objective. Branches are not just a Git feature; they are the backbone of collaborative software delivery.
How It Appears in Exam Questions
Scenario-based questions: The exam presents a scenario where a development team is working on multiple features simultaneously. You are asked to recommend a branching strategy that allows developers to work independently while ensuring code quality. The correct answer would involve feature branches with pull request policies triggered to main.
Configuration questions: These ask you to configure a branch policy in Azure Repos. For example, 'You need to ensure that all changes to the main branch are reviewed by at least two team members and that automated builds succeed before merging. What should you do?' The answer would involve creating a branch policy that requires a minimum number of reviewers and a status check for the build pipeline.
Troubleshooting questions: A developer reports that a merge conflict occurs when merging a feature branch into main. The question asks what command or process should be used to resolve the conflict. Options might include 'git merge --abort', 'git rebase', or manually editing conflicting files. The correct approach depends on the scenario, but typically the safe answer is to pull the latest main, resolve conflicts locally, commit, and push.
Another common pattern involves the 'git checkout' vs. 'git switch' commands, or the use of 'git branch -d' vs. '-D' to delete branches. Questions may also test your understanding of the commit history impact of merge vs. rebase. For instance, 'You want a linear commit history. Which strategy should you use?' The answer is rebase before merging, but with the caveat of not rebasing public branches.
Study AZ-400
Test your understanding with exam-style practice questions.
Example Scenario
You are a DevOps engineer at a company developing a mobile app called 'FitTracker'. The team follows a trunk-based development model with feature flags. The main branch is called 'main'. One day, a developer named Lisa is assigned to implement a new feature: 'Sleep Tracking'. She creates a branch called 'feature/sleep-tracking' from the latest main. Over the next two days, Lisa commits several changes to her branch, adding new code for sleep analysis and a new UI screen.
Meanwhile, another developer, Mike, is fixing a bug in the login screen. He creates his own branch 'fix/login-issue' from main. Both developers work independently. On the third day, Lisa finishes her feature and creates a pull request from 'feature/sleep-tracking' to 'main'. The branch policy requires at least one reviewer and a successful build. The build pipeline runs unit tests and code analysis. The build fails due to a syntax error. Lisa fixes the error, pushes a new commit, and the build passes. Her colleague reviews the code and approves the pull request. The branch is merged into main.
Because of branching, neither developer blocked the other. Lisa could work on her feature without worrying about Mike's changes, and vice versa. After merging, the new feature is deployed via a separate release pipeline. If Lisa's feature had introduced a critical bug, it would have been caught during the build or review before reaching main. This scenario is typical in exams to test your understanding of the branching workflow and policies.
Common Mistakes
Thinking a branch is a copy of the entire repository, consuming huge amounts of space.
Git branches are lightweight pointers, not full copies. They only store differences (commits) relative to the original branch. This makes branching very cheap.
Understand that a branch is just a reference to a commit. Use 'git branch' to see all pointers, and know that creating a branch takes almost no time or disk space.
Directly pushing to the main branch instead of using a feature branch and pull request.
Direct pushes bypass code review and testing, leading to potential bugs and instability. It also violates DevOps best practices for collaboration.
Always create a feature branch for any change, commit and push to that branch, then create a pull request for review. Use branch policies to enforce this.
Deleting a branch before its changes have been merged into the main branch.
If you delete a feature branch before merging, all its commits become unreachable and the work is lost permanently (unless you have another reference or the reflog).
Only delete a branch after it has been fully merged and the merge commit exists on the target branch. Use 'git branch -d' (safe delete) instead of '-D' (force delete) unless you are sure.
Confusing 'git merge' and 'git rebase' as the same operation.
Merge creates a merge commit that preserves the history of both branches, while rebase rewrites history by applying commits on top of another branch. Rebasing public branches can cause chaos for collaborators.
Use merge when collaborating on a shared branch (preserves context). Use rebase only on local private branches to keep a cleaner history.
Not updating a feature branch with the latest main before creating a pull request.
If the feature branch is far behind main, merging may cause many conflicts. It also means the feature has not been tested against the latest code.
Before creating a pull request, merge or rebase the latest main into your feature branch. Resolve any conflicts locally, then push the updated branch.
Exam Trap — Don't Get Fooled
{"trap":"On the AZ-400 exam, a scenario describes a developer working on a feature branch for a long time. The question asks how to integrate the latest changes from main into the feature branch with the least disruptive impact on the commit history. Many learners choose 'git merge main' without considering that it creates a merge commit that might clutter the history.
Alternatively, some choose 'git rebase main', unaware of the 'rebase onto' concept.","why_learners_choose_it":"Learners often memorize 'merge' as the default way to combine branches. They may not understand the trade-offs between merge and rebase in terms of history linearity and safety.
They also may not know that rebasing a public branch is dangerous.","how_to_avoid_it":"Study the differences: Merge preserves exact chronology and is safe for shared branches. Rebase rewrites history and should only be done on private feature branches.
For a long-lived feature branch, use 'git merge main' periodically to keep it up to date, then use a merge commit for the final PR. Remember the rule: 'Do not rebase branches that others might be working on.'
Step-by-Step Breakdown
Create a new branch
Use 'git branch <branch-name>' to create a new pointer at the current commit. This does not switch to the new branch. After creation, use 'git checkout <branch-name>' or 'git switch <branch-name>' to start working on it.
Make commits on the branch
As you modify files, stage them with 'git add' and commit with 'git commit'. Each commit moves the branch pointer forward. These commits are isolated from other branches.
Push the branch to the remote
Use 'git push -u origin <branch-name>' to upload your branch to the remote repository. The '-u' flag sets upstream tracking, simplifying future pushes. Now teammates can see your work.
Open a pull request
In Azure Repos or GitHub, open a pull request to propose merging your branch into the target branch (e.g., main). This triggers reviews, automated builds, and policy checks.
Review and merge
After approvals and passing checks, the pull request is merged. The target branch now includes your changes. You can choose merge, squash, or rebase merge depending on the desired history.
Delete the feature branch
Once merged, delete the feature branch locally with 'git branch -d <branch-name>' and remotely with 'git push origin --delete <branch-name>'. This keeps the repository clean.
Practical Mini-Lesson
In professional DevOps practice, branching is not just about creating pointers; it is about managing workflow. A common strategy is GitHub Flow, where every change is made on a short-lived branch with a pull request. For Azure DevOps, you may use GitFlow which adds a develop branch and release branches for more structured releases.
When configuring branch policies in Azure Repos, you must decide on the required number of reviewers, whether to reset code reviewer votes after a new commit, and which build pipelines must succeed. It is also important to enable 'Allow fork contributions to build pipelines' if your team uses forks. Misconfiguration can lead to security issues, such as a malicious pull request running an untrusted build.
One common pitfall is merge conflicts. When two branches modify the same lines of code, Git cannot automatically merge. The developer must manually resolve the conflict, mark it as resolved, and commit. In a pull request, Azure Repos shows a 'Conflicts' tab that requires resolution before merging. Professionals often use a merge conflict editor or pull the latest target branch into the feature branch to minimize conflicts.
Another key practice is squashing commits before merge. Instead of having many small commits like 'WIP', 'fix typo', 'update', you can squash them into one meaningful commit. This keeps the history clean. However, squashing loses the granularity of individual commits, so use it wisely.
Finally, understanding the difference between fast-forward and no-fast-forward merges is important. A fast-forward merge moves the target branch pointer directly to the source branch pointer if no divergence has occurred. A no-fast-forward merge (--no-ff) creates a merge commit even when a fast-forward is possible, preserving the fact that a branch existed. Many teams enforce --no-ff to maintain traceability.
Memory Tip
Think of a branch like a bookmark that moves as you read. The bookmark points to your current page (commit). You can have many bookmarks in the same book.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
A/B testing is a controlled experiment that compares two versions of a single variable to determine which one performs better against a predefined metric.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
Frequently Asked Questions
Can I create a branch from a specific commit instead of the latest commit?
Yes. Use 'git branch <branch-name> <commit-hash>' to create a branch at any existing commit. This is useful for hotfixes or reverting to a known good state.
What is the difference between a local branch and a remote-tracking branch?
A local branch is only on your machine. A remote-tracking branch (e.g., origin/main) is a local copy of a branch on the remote server. Remote-tracking branches are updated when you fetch from the remote.
How do I rename a branch in Git?
If you are on the branch you want to rename, use 'git branch -m <new-name>'. If you are on a different branch, use 'git branch -m <old-name> <new-name>'.
What happens if I push a branch with the same name as an existing remote branch?
It will overwrite the remote branch with your local version. To avoid overwriting, use 'git push --force-with-lease' instead of '--force' for safety.
Is it safe to delete a branch after merging?
Yes, once the branch has been merged into the target branch and the merge commit exists, it is safe to delete. The commits are still reachable through the merge commit.
Can I have multiple branches active at the same time?
Technically, yes, but you can only have one working directory checked out at a time. Git tracks which branch you are currently on. You can switch between branches using 'git checkout' or 'git switch'.
What is a 'detached HEAD' state?
A detached HEAD occurs when you checkout a specific commit instead of a branch. You are no longer on a branch, so new commits will not be associated with any branch and can be lost if you switch away.
Summary
A branch in Git is a lightweight, movable pointer to a commit that enables isolated development. It is one of the most powerful features of version control and a cornerstone of modern DevOps workflows. By using branches, teams can work on multiple features, fixes, or experiments simultaneously without interfering with the main codebase.
For IT professionals and certification candidates, mastering branching is critical. The AZ-400 exam specifically tests your ability to implement branching strategies, configure branch policies in Azure Repos, and manage pull requests. Understanding the difference between merge and rebase, when to delete branches, and how to resolve conflicts is essential.
Remember that branches are not copies; they are pointers. This makes them efficient and flexible. Use feature branches for every change, enforce branch policies to protect the main branch, and always keep your branches short-lived to minimize conflicts. The exam will reward practical, scenario-based knowledge over raw command memorization. Practice with Azure Repos, create pull requests, and experiment with branch policies to solidify your understanding.