# Branch An independent line of development in a version control system, used to isolate work on new features or bug fixes from the main codebase. **Pronunciation:** /bræntʃ/ **Difficulty:** Beginner **Synonyms:** line of development, codeline, stream **Categories:** Version Control, Software Development **Tags:** Git, VCS, Source Control, Development Workflow, Collaboration Canonical: https://scaleengineer.com/glossaries/branch --- ## Definitions - **Branch in Version Control Systems (VCS):** In the context of Version Control Systems (VCS) like Git, a **branch** is an independent line of development. It acts as a movable pointer to a specific commit in the project's history. The primary purpose of a branch is to isolate work, allowing developers to work on new features, bug fixes, or experiments without affecting the main, stable codebase (often called `main`, `master`, or `trunk`). ### Key Concepts * **Isolation**: Branches provide a contained space for changes. If the work on a branch is experimental and fails, it can be discarded without impacting other parts of the project. * **Parallel Development**: Multiple developers can work on different features simultaneously, each on their own branch. * **Lightweight Nature (in Git)**: Unlike older systems where branching might involve copying the entire directory structure, a branch in Git is just a simple file containing the 40-character SHA-1 hash of a commit. This makes creating and switching between branches extremely fast and efficient. ### Common Branching Workflows * **Feature Branching**: Create a new branch for each new feature (e.g., `feature/user-authentication`). Once the feature is complete and tested, it is merged back into the main branch. * **Release Branching**: When the `main` branch has enough features for a release, a `release` branch is created. This branch is used for final bug fixes and preparation for deployment, allowing the `main` branch to continue accepting features for the *next* release. * **Hotfix Branching**: If a critical bug is found in production, a `hotfix` branch is created from the production version tag. The fix is made here, tested, and then merged back into both `main` and the current `release` branch. ### Example Usage (Git) ```bash # View existing branches git branch # Create a new branch called 'new-login-feature' git branch new-login-feature # Switch to the new branch to start working on it git checkout new-login-feature # --- make changes and commit them --- git add . git commit -m "Add initial login form" # Switch back to the main branch git checkout main # Merge the completed feature branch into main git merge new-login-feature ``` ## Etymology The term 'branch' is a metaphor derived from a tree. Just as a new branch grows out from the main trunk or another larger branch, a software branch represents a new line of development that diverges from an existing one. This analogy effectively captures the idea of a separate but connected path of growth. ## First used 1970s ## Historical context The concept of branching has existed since the early days of version control, but its implementation and usability have evolved significantly. * **1970s-1980s (SCCS & RCS)**: Early systems like Source Code Control System (SCCS, 1972) and Revision Control System (RCS, 1982) had rudimentary branching capabilities. However, the process was often complex and cumbersome, discouraging frequent use. * **1990s (CVS)**: Concurrent Versions System (CVS) made branching more accessible. Branches, often called 'codelines' or 'streams', were more common but still considered a heavyweight operation. Merging changes between branches was notoriously difficult and error-prone, a situation often referred to as 'merge hell'. * **2000s (Subversion)**: Subversion (SVN) treated branches as cheap copies of directories within the repository. While an improvement over CVS, it was still a directory-level operation. A common convention was to have `/trunk`, `/branches`, and `/tags` directories. This model made branching more explicit but still lacked the fluidity of modern systems. * **Mid-2000s to Present (Git & Mercurial)**: The rise of Distributed Version Control Systems (DVCS) like Git (2005) revolutionized branching. In Git, a branch is not a copy of the codebase but a simple, lightweight pointer to a commit. This fundamental design change made branching and merging core, trivial operations. This efficiency enabled the widespread adoption of workflows like 'feature branching', where a branch is created for even the smallest change, fundamentally changing how developers collaborate and manage code. ## Q&A - **What is the primary purpose of creating a branch in a version control system?:** To isolate development work. It allows developers to work on new features, bug fixes, or experiments in a separate line of development without destabilizing the main or 'production-ready' codebase. - **In Git, what is a branch technically?:** A branch in Git is simply a lightweight, movable pointer to a specific commit. It's not a full copy of the codebase, which is why creating and switching between branches is extremely fast. - **What is the difference between a branch and a fork?:** A **branch** is a parallel line of development *within* a single repository. A **fork** is a completely separate, server-side copy of an entire repository, allowing someone to experiment or propose changes without having write access to the original repository. ## Usage examples - To start working on a new feature without affecting the main codebase, the developer created a new **branch**. - After the code review was approved, she merged her feature **branch** back into the `main` **line of development**. - We need to fix a critical bug in production, so let's create a hotfix **branch** from the latest release tag. - The team follows a strict workflow where every task is developed in its own **branch** before being integrated. ## Related terms - Trunk - Fork - HEAD - Checkout - Rebase - Feature Branch - Main/Master Branch ## Popular related terms - Git - Merge - Pull Request - Commit - Repository